How to use the "=>" operator in assignment expressions?

109 views
Skip to first unread message

Gonzalo Chumillas

unread,
Aug 30, 2016, 12:56:04 PM8/30/16
to Dart Misc
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

unread,
Aug 30, 2016, 1:26:02 PM8/30/16
to General Dart Discussion
You could do that, yes. F# calls it ignore. A simpler solution is to just not use =>. It's not buying you much in your example.

Cheers!

– bob

Matthew Butler

unread,
Aug 30, 2016, 2:15:56 PM8/30/16
to Dart Misc
+1

Just use braces:

void toggle() { isOpen = !isOpen; }

 

Lasse R.H. Nielsen

unread,
Aug 30, 2016, 4:25:08 PM8/30/16
to mi...@dartlang.org
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!'

--
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 email to misc+uns...@dartlang.org.



--
Lasse R.H. Nielsen - l...@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

unread,
Aug 30, 2016, 4:44:41 PM8/30/16
to General Dart Discussion

On Tue, Aug 30, 2016 at 1:24 PM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:
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

unread,
Aug 30, 2016, 5:49:42 PM8/30/16
to Dart Misc
+1
Setters look like boilerplate when next to getters.

Lasse R.H. Nielsen

unread,
Aug 31, 2016, 2:14:03 AM8/31/16
to mi...@dartlang.org

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


On Aug 30, 2016 11:49 PM, "Filipe Morgado" <pix...@gmail.com> wrote:
+1
Setters look like boilerplate when next to getters.

Danny Tuppeny

unread,
Aug 31, 2016, 2:58:41 AM8/31/16
to mi...@dartlang.org
On Tue, 30 Aug 2016 at 22:49 Filipe Morgado <pix...@gmail.com> wrote:
+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

unread,
Aug 31, 2016, 8:12:31 AM8/31/16
to Dart Misc
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.

Filipe Morgado

unread,
Aug 31, 2016, 8:21:06 AM8/31/16
to Dart Misc
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.

Lasse R.H. Nielsen

unread,
Aug 31, 2016, 9:09:00 AM8/31/16
to mi...@dartlang.org
On Wed, Aug 31, 2016 at 2:12 PM, Filipe Morgado <pix...@gmail.com> wrote:
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.'

Danny Tuppeny

unread,
Aug 31, 2016, 12:34:15 PM8/31/16
to mi...@dartlang.org
On Wed, 31 Aug 2016 at 13:21 Filipe Morgado <pix...@gmail.com> wrote:
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.

Bob Nystrom

unread,
Aug 31, 2016, 3:58:27 PM8/31/16
to General Dart Discussion

On Wed, Aug 31, 2016 at 6:08 AM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:
  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

unread,
Sep 1, 2016, 3:06:45 AM9/1/16
to mi...@dartlang.org
On Wed, Aug 31, 2016 at 9:57 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Wed, Aug 31, 2016 at 6:08 AM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:
  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!
 

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

Erik Ernst

unread,
Sep 1, 2016, 5:15:40 AM9/1/16
to Dart Misc
On Thu, Sep 1, 2016 at 9:06 AM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:
On Wed, Aug 31, 2016 at 9:57 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:
On Wed, Aug 31, 2016 at 6:08 AM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:
  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).
 
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 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!
 

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 - l...@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

--
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 email to misc+uns...@dartlang.org.



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

Bob Nystrom

unread,
Sep 1, 2016, 1:16:39 PM9/1/16
to General Dart Discussion
On Thu, Sep 1, 2016 at 12:06 AM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:
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.

We, do, but note that these are not braced.
 
Do we allow one-line "while" statements?

Nope. It's only if.
 

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. :-/
 

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!

:D
 
 

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

Reply all
Reply to author
Forward
0 new messages