Add support for interleaved parameters on method signatures / calls

[DartBot]

This issue was originally filed by [email protected]

---

I understand that Dart is shooting for a familiar feel to most c languages and therefore I would expect support for the familiar "dot notation" method call style and grouped parameters. But for those of us that like languages that give the ability to have self documenting code, why not add support for smalltalk-esque keyword messages as well? It wouldn't have to be something as unfamiliar as:

object doSomethingUsingThing: thing withOtherThing: otherThing.

But how about something like:

object.doSomethingUsingThing(thing)withOtherThing(otherThing);

This would be supported with the associated method declaration syntax:

void doSomethingUsingThing(Thing aThing)withOtherThing(Thing otherThing) { ... }

The language could allow calling this method with both styles provided some formatting standard is agreed to, so using the usual calling syntax this could also be called with something like:

object.doSomethingUsingThing_withOtherThing_(thing, otherThing);

Would this really be any more unfamiliar to most Java/JavaScript developers than the equally unfamiliar optional named parameters?

[dgrove]

Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

[gbracha]

Added Accepted label.

[munificent]

This would of course collide with the current named argument syntax, but a while back I toyed with this in Smalltalk:

  object doSomethingUsingThing: thing withOtherThing: otherThing

Translating to something like this in Dart:

  object.doSomething(usingThing: thing, withOtherThing: otherThing)

[gbracha]

The named parameter syntax may be revisited, so there are possibilities ...

[DartBot]

This comment was originally written by [email protected]

---

@bob, that seems pretty readable to me, but, correct me if I'm wrong, using named args the method signature is still "doSomething" in each case since there's no method overloading in Dart, meaning that if I were to add another parameter like in "doSomething(usingThing: thing, withOtherThing: otherThing andYetAnotherThing: anotherThing)", this would conflict. So to support the use of the extra parameter, it seems the only way would be to have a very monolithic method that checks for the presence of each parameter in its implementation and does varying behavior conditionally to support all the different combinations of parameters. This seems less maintainable to me.

[munificent]

The idea is that those "named parameters" would actually be part of the method name itself. So you could think of:

  object doSomething(usingThing: thing, withOtherThing: otherThing)

as being kind of like syntactic sugar for:

  object doSomething_usingThing_withOtherThing(thing, otherThing)

[DartBot]

This comment was originally written by [email protected]

---

Ah, in that case, that's great too. I'd be happy with either solution. Are you following any other languages' leads on these? Maybe I'm just extremely ignorant, but I don't know any languages where the named params become part of the method signature. In that case, would it also be possible to change the named parameter argument order in a call? I see this as a staple of most named argument implementations that I've seen, but I wonder how it could work if the arguments change the signature.

[munificent]

Are you following any other languages' leads on these?

Not really. It was just my attempt to get Smalltalk-style keyword selectors to look "right" in a C-derived syntax. (For what it's worth, my hobby language Magpie supports this behavior too, more or less, but going about it in a different way.)

In that case, would it also be possible to change the named parameter argument order in a call?

No, it wouldn't. Personally, I think that would be OK because in most places where you would use this there is likely an obviously right order. You would do "example".substring(from: 1, to: 2) but "example".substring(to: 2, from: 1) reads kind of funny.

It is very different from named arguments in other languages. It looks the same, but the semantics are very distinct. That's probably the main argument against it.

[DartBot]

This comment was originally written by [email protected]

---

Well for my personal preference, I'd be happy with whichever syntactical format, as long as the result is ultimately more descriptive selectors/signatures. I suppose some could argue that I can already be as descriptive as I want with the regular grouped parameter syntax by having method names like doSomethingUsingThing_andOtherThing_, but this is both generally difficult for humans to parse and is too 'different' to make a convention.

I think if the language provides the convention as an option, in a format that seems to mesh with the regular call styles, then more people would be encouraged to use it. But as you said:

It looks the same, but the semantics are very distinct. That's probably the main argument against it.

The difficulty is going to be to pick the least unfamiliar and least surprising syntactical construct for this to gain acceptance with most c-style familiarized developers.

[DartBot]

This comment was originally written by [email protected]

---

A minor improvement over the current state would be allowing positional arguments to be optionally named. (You'd still have to get the position right).

So with:
class Point {
  void move(int x, int y);
}

these are equivalent:
move(x:4, y:2);
move(4, 2);
move(4, y:2);

and these are errors
move(x:4);
move(y:4, x:2);

[DartBot]

This comment was originally written by [email protected]

---

An improvement, yes. I really hope we can do better though, and really hopefully before development of core api's is so far ahead with the existing syntax that it would be too much work to go back and add named versions of the core library apis.

[anders-sandholm]

We decided to keep named parameters rather than introducing keyword sends (as in Smalltalk) into Dart. We realize this is a matter of taste.

---

Added WontFix label.

[DartBot]

This comment was originally written by [email protected]

---

Disappointing. Would there be any consideration for something like "non-optional" named arguments, where essentially calls would look like doSomething(withX:x, withY:y)? Or is this not worth making a request for?