[dart-misc] How to use the "=>" operator in assignment expressions?

[Gonzalo Chumillas]

The following function declaration is wrong, since the "isOpen = !isOpen"
expression returns a boolean value:

// not good
void toggle => isOpen = !isOpen;


How could I use the "=>" operator in the above expression? I was thinking
in something like this:

void toggle => shutUp(isOpen = !isOpen);

Where 'shutUp' is a function that returns void.

Thanks.

['Bob Nystrom' via Dart Misc]

On Tue, Aug 30, 2016 at 6:07 AM, Gonzalo Chumillas <

Post by Gonzalo Chumillas
The following function declaration is wrong, since the "isOpen = !isOpen"
// not good
void toggle => isOpen = !isOpen;
How could I use the "=>" operator in the above expression? I was thinking
void toggle => shutUp(isOpen = !isOpen);
Where 'shutUp' is a function that returns void.

You could do that, yes. F# calls it ignore
<https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual/operators.ignore%5B't%5D-function-%5Bfsharp%5D>.
A simpler solution is to just not use =>. It's not buying you much in your
example.

Cheers!

– bob

[Matthew Butler]

Post by 'Bob Nystrom' via Dart Misc

Post by Gonzalo Chumillas
The following function declaration is wrong, since the "isOpen = !isOpen"
// not good
void toggle => isOpen = !isOpen;
How could I use the "=>" operator in the above expression? I was thinking
void toggle => shutUp(isOpen = !isOpen);
Where 'shutUp' is a function that returns void.

You could do that, yes. F# calls it ignore
<https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual/operators.ignore%5B't%5D-function-%5Bfsharp%5D>.
A simpler solution is to just not use =>. It's not buying you much in
your example.
Cheers!
– bob

+1

Just use braces:

void toggle() { isOpen = !isOpen; }

['Lasse R.H. Nielsen' via Dart Misc]

Seconded!

The "=> expression;" notation is basically a shorthand for "{ return
expression; }".
If you wouldn't write the return, you shouldn't use the arrow either.
It gives the impression that the function is returning something, which it
really isn't, so you are misleading the reader.

/L 'don't mislead the reader!'

Post by Matthew Butler

Post by 'Bob Nystrom' via Dart Misc

Post by Gonzalo Chumillas
The following function declaration is wrong, since the "isOpen =
// not good
void toggle => isOpen = !isOpen;
How could I use the "=>" operator in the above expression? I was
void toggle => shutUp(isOpen = !isOpen);
Where 'shutUp' is a function that returns void.

You could do that, yes. F# calls it ignore
<https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual/operators.ignore%5B't%5D-function-%5Bfsharp%5D>.
A simpler solution is to just not use =>. It's not buying you much in
your example.
Cheers!
– bob

+1
void toggle() { isOpen = !isOpen; }
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

['Bob Nystrom' via Dart Misc]

On Tue, Aug 30, 2016 at 1:24 PM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
If you wouldn't write the return, you shouldn't use the arrow either.

I agree, but with the caveat that it's *super annoying* that you can't
naturally use "=>" for setters. :-/

– bob

[Filipe Morgado]

+1
Setters look like boilerplate when next to getters.

['Lasse R.H. Nielsen' via Dart Misc]

Do we need a shorthand syntax for function bodies that are single
expressions that are NOT returned?

Or will the problem go away if we start consistently treating "void" as
"Object that you can't use.

/L

Post by Filipe Morgado
+1
Setters look like boilerplate when next to getters.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Filipe Morgado]

I agree but ...

void set myValue(value) => _myValue = value;

Not sure how this would work in strong mode when we're declaring 'void' but
are actually returning a value.

void set myValue(value) => void(_myValue = value);

As Gonzalo suggested, maybe it would take an extra keyword to treat a value
as void.


On Wednesday, 31 August 2016 07:14:03 UTC+1, Lasse Reichstein Holst Nielsen

Post by 'Lasse R.H. Nielsen' via Dart Misc
Do we need a shorthand syntax for function bodies that are single
expressions that are NOT returned?
Or will the problem go away if we start consistently treating "void" as
"Object that you can't use.
/L

Post by Filipe Morgado
+1
Setters look like boilerplate when next to getters.
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Lasse R.H. Nielsen' via Dart Misc]

Post by Filipe Morgado
I agree but ...
void set myValue(value) => _myValue = value;
Not sure how this would work in strong mode when we're declaring 'void'
but are actually returning a value.
void set myValue(value) => void(_myValue = value);
As Gonzalo suggested, maybe it would take an extra keyword to treat a
value as void.

Or just use
void set myValue(value) { _myValue = value; }
and drop the =>. It is *one* character longer (but two of the characters
requires you to press shift, instead of just one, which does suck a bit).

If you start adding a `void` operator or function wrapper, you are adding
5-6 more characters, and then braces start to look really good.

/L 'You probably won't get a => setter through a code-review with me
reviewing it.'
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

['Bob Nystrom' via Dart Misc]

On Wed, Aug 31, 2016 at 6:08 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
void set myValue(value) { _myValue = value; }
and drop the =>. It is *one* character longer

The formatter will split that { ... } into three lines. It could make an
exception for cases like this, but that feels a little fishy.

Personally, I'd be happy if => just discarded the result if used for a
void-returning declaration.

– bob

['Lasse R.H. Nielsen' via Dart Misc]

On Wed, Aug 31, 2016 at 9:57 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Wed, Aug 31, 2016 at 6:08 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
void set myValue(value) { _myValue = value; }
and drop the =>. It is *one* character longer

The formatter will split that { ... } into three lines. It could make an
exception for cases like this, but that feels a little fishy.

I'd approve of that exception. If an entire function body consists of one
statement, and it all fits on the same line as the function header, keep it
as a one-liner. We already allow one-line "if" statements. Do we allow
one-line "while" statements?

foo(bar) { throw new FooTheBar(bar); }
foo2(bar) { if (bar != baz) throw new FooTheBar(bar); }
foo3(bar) { while (bar > 0) print(--bar); }

Yep, works for me.

Also, if I used the formatter, I wouldn't worry about the look, and then
writing:
foo(value){_myValue=value;}
is actually *shorter* than:
foo(value)=>_myValue=value;
and the formatter would insert the whitespace for me. My editor would
probably even add the final brace when I type the leading one. Two
characters less!

Post by 'Bob Nystrom' via Dart Misc
Personally, I'd be happy if => just discarded the result if used for a
void-returning declaration.

That is an interesting option. We special-case void in other ways, and in
Strong-mode/Dart 2 the type annotation can affect the behavior.

If we could disallow `=>` for void functions, we can also special-case it
in other ways.

/L
--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

['Erik Ernst' via Dart Misc]

On Thu, Sep 1, 2016 at 9:06 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
On Wed, Aug 31, 2016 at 9:57 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Wed, Aug 31, 2016 at 6:08 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc
void set myValue(value) { _myValue = value; }
and drop the =>. It is *one* character longer

The formatter will split that { ... } into three lines. It could make an
exception for cases like this, but that feels a little fishy.

I'd approve of that exception.

Yes please! The fact that `=>` is so much more compact may be the main
reason why we have these spurious "return void" situations in the first
place (so "char count goes up by 1!" may disappear in the noise whereas
"line count goes up by 2!" really matters).

Post by 'Lasse R.H. Nielsen' via Dart Misc
If an entire function body consists of one statement, and it all fits on
the same line as the function header, keep it as a one-liner. We already
allow one-line "if" statements. Do we allow one-line "while" statements?
foo(bar) { throw new FooTheBar(bar); }
foo2(bar) { if (bar != baz) throw new FooTheBar(bar); }
foo3(bar) { while (bar > 0) print(--bar); }
Yep, works for me.

Me, too!

Also, if I used the formatter, I wouldn't worry about the look, and then

Post by 'Lasse R.H. Nielsen' via Dart Misc
foo(value){_myValue=value;}
foo(value)=>_myValue=value;
and the formatter would insert the whitespace for me. My editor would
probably even add the final brace when I type the leading one. Two
characters less!

Post by 'Bob Nystrom' via Dart Misc
Personally, I'd be happy if => just discarded the result if used for a
void-returning declaration.

That is an interesting option. We special-case void in other ways, and in
Strong-mode/Dart 2 the type annotation can affect the behavior.
If we could disallow `=>` for void functions, we can also special-case it
in other ways.
/L
--
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
---
You received this message because you are subscribed to the Google Groups
"Dart Misc" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

['Bob Nystrom' via Dart Misc]

On Thu, Sep 1, 2016 at 12:06 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
The formatter will split that { ... } into three lines. It could make an

Post by 'Bob Nystrom' via Dart Misc
exception for cases like this, but that feels a little fishy.

I'd approve of that exception. If an entire function body consists of one
statement, and it all fits on the same line as the function header, keep it
as a one-liner. We already allow one-line "if" statements.

We, do, but note that these are *not* braced.

Post by 'Bob Nystrom' via Dart Misc
Do we allow one-line "while" statements?

Nope. It's only if.

Post by 'Bob Nystrom' via Dart Misc
foo(bar) { throw new FooTheBar(bar); }
foo2(bar) { if (bar != baz) throw new FooTheBar(bar); }
foo3(bar) { while (bar > 0) print(--bar); }

That's a little dense for my taste. :-/

Post by 'Bob Nystrom' via Dart Misc
Yep, works for me.
Also, if I used the formatter, I wouldn't worry about the look, and then
foo(value){_myValue=value;}
foo(value)=>_myValue=value;
and the formatter would insert the whitespace for me. My editor would
probably even add the final brace when I type the leading one. Two
characters less!

:D

Post by 'Bob Nystrom' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
Personally, I'd be happy if => just discarded the result if used for a
void-returning declaration.

That is an interesting option. We special-case void in other ways, and in
Strong-mode/Dart 2 the type annotation can affect the behavior.

Right. Strong mode already has an exception around setters, I think,
specifically because too many users use => for them. So it would just be
generalizing that exception to all void members, and discarding the result.

Cheers!

– bob

[Danny Tuppeny]

Post by Filipe Morgado
+1
Setters look like boilerplate when next to getters.

I'm curious; why would you write a getter/setter at all if all it does is
expose a field? (It's possible *you're* not, but I get the impression many
are from the direction of this conversation).

In C# we did this (actually, we use auto-properties now) because there's a
difference in compiled code that calls a property vs a field, so changing
from a public field to a property was a breaking change. This isn't the
case in Dart, so if all you're doing is this:

String _name;
String get name => _name;
set name(String value) { _name = value; }

Then why not just replace the entire thing with:

String name;

? If in the future if you need to add logic, you can change it?

[Filipe Morgado]

I fully agree with you and that's a great detail about Dart.

However I use getters/setters a lot for derived properties, and those are
usually one-liners.

void set url(String value) { _request.url = value; }
void set angleDegrees(value) { _angle = value * Math.PI / 180; }
void set rotation(value) { _typedData[4] = value; }

One-line functions are less common, but the same applies.

Post by Danny Tuppeny

Post by Filipe Morgado
+1
Setters look like boilerplate when next to getters.

I'm curious; why would you write a getter/setter at all if all it does is
expose a field? (It's possible *you're* not, but I get the impression
many are from the direction of this conversation).
In C# we did this (actually, we use auto-properties now) because there's a
difference in compiled code that calls a property vs a field, so changing
from a public field to a property was a breaking change. This isn't the
String _name;
String get name => _name;
set name(String value) { _name = value; }
String name;
? If in the future if you need to add logic, you can change it?

[Danny Tuppeny]

Post by Filipe Morgado
I fully agree with you and that's a great detail about Dart.
However I use getters/setters a lot for derived properties, and those are
usually one-liners.
void set url(String value) { _request.url = value; }
void set angleDegrees(value) { _angle = value * Math.PI / 180; }
void set rotation(value) { _typedData[4] = value; }
One-line functions are less common, but the same applies.

Yeah, I figured it was valid in many cases but wondered if maybe in a lot
of cases people were creating needless wrappers through habit or assuming
the reasons people did it elsewhere applied to Dart. I haven't written (or
reviewed) a lot off Dart, so I'm not really sure how common these things
are.