Shorter syntax for common object property definition idiom.
http://es6-features.org/#PropertyShorthand
It would also be nice for named parameters.
The idea seems to be that in a position where a name and value is required, but only a single identifier is provided, treat that identifier as both the name and the value.
Dart doesn't really have any positions where that is the case syntactically because the only place we have names and values is named arguments, and there a single expression can also mean a positional argument. We would have to use the static type of the function being called to distinguish whether foo(x) means foo(x) or foo(x: x). That's too fragile and error-prone.
What we could do instead would be introducing a shorthand syntax like foo(:x) which marks this as a named argument, but leaves the name to be inferred from the expression, which must then be a single identifier.
It would make forwarding named parameters much easier:
class Something extends Other {
foo(int a, {int bar, int baz, int qux}) => super.foo(a, :bar, :baz, :qux);
}
(It's a good syntax, though, which we then can't use for anything else).
I think I'd prefer a simple way to forward all arguments over this:
class Something extends Other {
foo(int a, {int bar, int baz, int qux}) = super.foo;
}
but it's not impossible.
@lrhn thanks for your answer, I understood. I like shorthand syntax - foo(:x)
I'd suggest putting the : _after_ the variable name – foo(x:)
That's because auto-complete naturally write x:
Most helpful comment
The idea seems to be that in a position where a name and value is required, but only a single identifier is provided, treat that identifier as both the name and the value.
Dart doesn't really have any positions where that is the case syntactically because the only place we have names and values is named arguments, and there a single expression can also mean a positional argument. We would have to use the static type of the function being called to distinguish whether
foo(x)meansfoo(x)orfoo(x: x). That's too fragile and error-prone.What we could do instead would be introducing a shorthand syntax like
foo(:x)which marks this as a named argument, but leaves the name to be inferred from the expression, which must then be a single identifier.It would make forwarding named parameters much easier:
(It's a good syntax, though, which we then can't use for anything else).
I think I'd prefer a simple way to forward all arguments over this:
but it's not impossible.