Positional and optional parameter syntax is unwarranted #6496
Comments
|
I'll double-down on C# syntax. While I try hard not to be a blind fan boy "do what Anders does", in this case I think the C# impl is easier and more flexible. |
|
This comment was originally written by jirkad...@gmail.com I would love to see the design reasons explained behind the current positional and optional parameter syntax. I somehow feel there might be some additional gain over the C♯ style. |
|
+1, I found the new behavior very surprising: * syntax is weirdly different: [bool foo = 42] vs {bool foo: 42}. * cannot combine optional positional and named. This means if I publish an API with an optional positional argument, I can never add a named argument later (or vice versa!). The only rule we could come up with is: never use optional positional arguments, unless you only have 1, and you don't think you'll ever need more (for example: String.substring). Everything else should use optional named arguments. Maybe this is a different issue but: the "?" prefix operator is completely broken. You can't even wrap a function anymore, without exponential explosion: // if "bar" uses ? inside -- callers beware! foo({x, y, z}) { Madness... Added Area-Language, Triaged labels. |
|
Set owner to @gbracha. |
|
I agree with John. I'm glad the new behavior solves the one problem it set out to solve (unintentionally baking a parameter name into your public API) but I don't understand why we prioritized solving that problem over all of the problems the new behavior creates and the existing problems that it doesn't solve. |
|
This comment was originally written by Don.J.Olms...@gmail.com I know you discussed this on the mailing list Bob, but I'm still at a loss as to how baking a parameter name into your public API is a bad thing. If you subclass and override a method you should be using the same names as the method you're overriding. If you're using a named parameter and the name changes your code should break. With this particular change in the HTML library there's a TON of code breakage for little to no benefit. There is really no precedence for this change in any other language and it makes things more complicated than necessary [] for optional {} for named. Other languages just have = and then the parameter is optional, thus negating the need for [], and some go the extra mile and provide for named parameters, making everything being able to passed in by the parameter name and not requiring {}. |
It isn't. Baking a parameter name into your public API unintentionally is. With the old syntax, let's say you wanted to have some optional positional parameter: foo([bar]) { ... } Find and dandy, but you've also made that parameter named. So now, like it or not, "bar" is part of foo's public API and you're stuck with it. This is the problem they were trying to fix with the new syntax. Personally, I think this is a pretty small problem. When C# added optional parameters they made them all named too. I don't know why Dart's designers chose to care about this and change a bunch of other things in the process of fixing it. |
|
This comment was originally written by ladicek@gmail.com I always felt like there is a tiny little thing about optional parameters in Dart that doesn't suit me, but I couldn't find the words. This is it. Totally agree with Don. |
|
This comment was originally written by sig...@gmail.com In the context of Don's C# comparison, and Bob's comment about Therefore, as far as this issue is concerned, I vote for the C# style. There should not be a separate syntax for declaring named parameters. Alternatively, please provide a syntax for required named parameters. Mandatory disambiguation :-). |
|
Added this to the M2 milestone. |
|
I clearly disagree with comment 9 (which states that every argument name should be part of the signature), but I do feel restricted when designing the core-library. Clearly we would prefer to have similar signatures for the extendable and the fixed-length constructors: |
|
I take it back. I don't want Dart to support the C#-style positional/named arguments model. The C# model does not have a way to require users to use names. They can just provide args in the correct order. So as an API author, the only way I can modify the args list is to add new items at the end to ensure nothing is broken. If I remove an argument somewhere in the middle I don't just break folks who specify that arg, but potentially any user that specifies arguments up to that point in the arg list. The Dart model, while a tiny bit more typing up front, is much better for future-proofing APIs and minimizing the impact of breaking changes. Well played. From my G+ post: https://plus.google.com/u/0/110066012384188006594/posts/2ZfpJkNcV4a |
|
This comment was originally written by ha...@gmail.com One piece of missing functionality for me is: right now there is no way to have a named parameter that is non-optional. The only way to make it mandatory is by dropping it's name and giving it a position... I'd love the ability to give named parameters in any order and still being able to declare that one or several of those HAVE to be given when you call the method (again no matter in what order) |
|
This comment was originally written by hachre...@gmail.com Wouldn't a syntax like this be viable? someMethod(String name: required, num age: required, String address, int postalCode, String countryCode: "US"); Here the String field name and the num field age would be set as required. If the call to the method doesn't declare them it's an exception. We can use that spot that would normally be used to give a default value because we require a set value on the method call. The field address and postalCode are optional and have no default value. And finally the field countryCode is optional and has the default value "US". The positions of any of those parameters would not matter. The moment you use this syntax you should no longer be able to use the positional syntax in the same method declaration to avoid problems. No good? |
|
Removed this from the Later milestone. |
|
Removed Oldschool-Milestone-Later label. |
|
I think the language is far enough along now that it is unlikely we'll change this. Added WontFix label. |
DartBot
added
Type-Enhancement
area-language
kevmoo
added
closed-not-planned
This issue was originally filed by Don.J.Olm...@gmail.com
Dart introduces additional syntax to support positional and named arguments. This goes against various other languages that support optional and positional arguments where no additional syntatic sugar is needed, and creates an additional hurdle to learn the language.
In C# arguments can be passed by name or by position. As an example from http://msdn.microsoft.com/en-us/library/dd264739.aspx, If you had the following method
static int CalculateBMI(int weight, int height)
It could be invoked in the following ways
CalculateBMI(123, 64);
CalculateBMI(weight: 123, height: 64);
CalculateBMI(height: 64, weight: 123);
CalculateBMI(123, height: 64);
However it cannot be invoked like this, as positional arguments cannot follow a named argument
//CalculateBMI(weight: 123, 64);
For optional arguments the same rules apply
static public void ExampleMethod(
int required,
string optionalstr = "default string",
int optionalint = 10)
ExampleMethod(3, optionalint: 4);
ExampleMethod(3, "a string", 4);
However it can not be invoked positionally without specifying all the values up to that point
//ExampleMethod(3, ,4);
So in C# all methods can be invoked with either named or positional arguments. No additional syntax is required. Optional parameters have their values specified by using assignment in the declaration.
Dart syntax for named/optional parameters is different and provides no additional gain. See http://rosettacode.org/wiki/Named_parameters for examples on other language's implementation, such as Python which provides a similar implementation.
The text was updated successfully, but these errors were encountered: