I did a search through the 1.5 src dir with the regexes for {\s+select, for
{\s+if, and for {\s+if, and manually filtered out cases where the loop had
multiple statements. for-select appears *26 times*, for-switch twice and
for-if only once.
A Github search in the form '"for X" language:go' also shows much higher
frequency of for-select than others.
for-select also appears twice in the concurrency section of the Go Tour, on pages
5 and 6 <
https://tour.golang.org/concurrency/5>, and there are no instances
of either for-switch or for-if throughout the Tour.
If nothing else, an order of magnitude greater frequency would justify why
for-select gets special treatment above for-switch and for-if. Any time you
communicate with a goroutine over multiple channels more than once (e.g.
any event loop), or consuming/populating a channel while waiting for a
signal or timer, you're likely using a for-select loop. This pattern is
used much more than just occasionally.
As was mentioned earlier in the thread, the behavior of bare continues and
breaks inside for { select { } } are confusingly equivalent, and the only
way to break out of the loop is to assign it a label and using a labeled
break. This proposal would add back the semantic difference between break
and continue without the cognitive overhead of understanding the
infrequently used labels.
As far as an extra control structure goes, this proposal wouldn't need to
touch the compiler past the AST, since the proposed combination could
easily be massaged into the two separate component statements with implicit
labels as seen earlier in the thread.
Because this specific construct is so pervasive, because it simplifies
continue and break statements, and because it alleviates mental overhead by
reducing the necessity of labels and reduces lines and levels of
indentation, this change is worth the small addition to the AST. Of course,
that's just my opinion, and others may still think the cost outweighs the
benefits.
:)
On Thursday, September 3, 2015 at 12:44:34 PM UTC-5, José Colón wrote:Well, if the costs outweigh the benefits then Go's just fine the way it
is. And keeping it small and simple are key to its success. :)
On Thursday, September 3, 2015 at 1:27:01 PM UTC-4, Rob 'Commander' Pike
wrote:
One already has for and select, and they combine perfectly as is. There
is no need to introduce a new data structure like this. Yes, would save a
line or two and maybe some indentation, but only for the occasional
program, and at the cost of another control structure, more documentation,
and justification for why this gets special treatment but for switch
doesn't and for if doesn't and so on. The benefit doesn't outweigh the cost.
The intent of Go is not to make everything as short as possible, but as
clear as possible.
-rob
On Thu, Sep 3, 2015 at 9:53 AM, Nick Patavalis <
[email protected]>
wrote:
On Thursday, September 3, 2015 at 7:47:21 PM UTC+3, Nick Patavalis wrote:On Thursday, September 3, 2015 at 7:41:12 PM UTC+3, Daniel Skinner
wrote:
There is no need for such labels with "for select", which is an added
benefit (I think).
So your example would look like this:
http://play.golang.org/p/oNmrr4WZ-dWhich, for me, is much more readable...
/npat
--
You received this message because you are subscribed to the Google
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
[email protected].
For more options, visit
https://groups.google.com/d/optout. --
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
[email protected].
For more options, visit
https://groups.google.com/d/optout.
