FAQ
Maybe this is naive, but I see the use of select statements inside infinite
for loops over and over, and it's a really useful construct. I thus wonder
if the language could have a "for select" statement.

for select {
   case c <- 1:
   case c <- 0:
}

instead of

for {
   select {
     case c <- 1:
     case c <- 0:
   }
}

I know it's just saving us from typing two curly braces, but it may make
code cleaner?

--
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nick Patavalis at Sep 3, 2015 at 2:53 pm
    Second!

    Mostly because it saves valuable horizontal space (i.e. one indent level less).

    /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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Christian von Kietzell at Sep 3, 2015 at 3:01 pm
    gofmt actually indents case to the same level as select, doesn't it?

    Nick Patavalis <nick.patavalis@gmail.com> schrieb am Do., 3. Sep. 2015
    16:54:
    Second!

    Mostly because it saves valuable horizontal space (i.e. one indent level
    less).

    /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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Sep 3, 2015 at 3:11 pm

    On Thursday, September 3, 2015 at 6:02:07 PM UTC+3, Christian von Kietzell wrote:

    gofmt actually indents case to the same level as select, doesn't it?
    Still, bar() below saves more horizontal space than foo()...

    func foo() {
        for {
    select {
    case a:
    qux()
    case b:
    qux()
    }
    }
    }

    func bar() {
    for select {
    case a:
    qux()
    case b:
    qux()
    }
    }

    /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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Christian von Kietzell at Sep 3, 2015 at 3:53 pm
    Except that now the cases are aligned with for, which looks weird.

    Nick Patavalis <nick.patavalis@gmail.com> schrieb am Do., 3. Sep. 2015
    17:11:
    On Thursday, September 3, 2015 at 6:02:07 PM UTC+3, Christian von Kietzell
    wrote:
    gofmt actually indents case to the same level as select, doesn't it?
    Still, bar() below saves more horizontal space than foo()...

    func foo() {
    for {
    select {
    case a:
    qux()
    case b:
    qux()
    }
    }
    }

    func bar() {
    for select {
    case a:
    qux()
    case b:
    qux()
    }
    }

    /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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Sep 3, 2015 at 4:03 pm

    On Thursday, September 3, 2015 at 6:53:32 PM UTC+3, Christian von Kietzell wrote:

    Except that now the cases are aligned with for, which looks weird.
    Aligned with "for select", which looks ok (to me).

    There is also the issue of what to do with "break". One possible
    interpretation is: "break" exits the "for select" loop, and "continue"
    re-enters the select.

    Anyway, I can certainly live without it, but the bar() example above looks
    too nested to me for such a (very) common case (it pushes the "meat" of the
    function too far right).

    /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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Sep 3, 2015 at 4:06 pm

    On Thursday, September 3, 2015 at 7:03:13 PM UTC+3, Nick Patavalis wrote:


    but the bar() example above
    I mean the foo() example

    /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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Skinner at Sep 3, 2015 at 4:40 pm
    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    On Thu, Sep 3, 2015 at 11:06 AM Nick Patavalis wrote:



    On Thursday, September 3, 2015 at 7:03:13 PM UTC+3, Nick Patavalis wrote:

    but the bar() example above
    I mean the foo() example

    /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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Sep 3, 2015 at 4:47 pm

    On Thursday, September 3, 2015 at 7:41:12 PM UTC+3, Daniel Skinner wrote:
    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    There is no need for such labels with "for select", which is an added
    benefit (I think).

    As I wrote in the previous post:

    - "break" exits the loop (since "for select" is a looping construct)
    - "continue" re-enters the select (again, since "for select" is a looping
    construct)

    /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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Sep 3, 2015 at 4:54 pm

    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:

    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    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-d

    Which, 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rob Pike at Sep 3, 2015 at 5:26 pm
    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 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:

    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    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-d

    Which, 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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Sep 3, 2015 at 5:34 pm

    On Thu, Sep 3, 2015 at 8:26 PM, Rob 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.
    True. I can't argue with this. It's not an essential feature. It would
    be neat (to my eyes) but others may not agree.
    As for "if select" and "switch select" I can't think of any meaningful
    semantics for these...

    /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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • José Colón at Sep 3, 2015 at 5:44 pm
    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 <nick.pa...@gmail.com
    <javascript:>> 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:

    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    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-d

    Which, 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 golang-nuts...@googlegroups.com <javascript:>.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Joe Taber at Sep 3, 2015 at 9:10 pm
    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 <nick.pa...@gmail.com>
    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:
    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    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-d

    Which, 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 golang-nuts...@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rob Pike at Sep 3, 2015 at 9:13 pm
    Thank you for doing the census, that's very thoughtful. But out of the
    better part of a million lines of code, 26 appearances doesn't justify
    terms like "pervasive". I do not believe the language is burdened by the
    lack of a combined for-select.

    -rob

    On Thu, Sep 3, 2015 at 2:10 PM, Joe Taber wrote:

    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 <nick.pa...@gmail.com>
    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:
    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    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-d

    Which, 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 golang-nuts...@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Lucio at Sep 4, 2015 at 9:41 am
    I found the following:

    "One stylistic novelty was the introduction of “guarded commands,” a highly
    elegant notational device that is equally applicable to alternative and
    repetitive programming constructs and thus became the preferred vehicle for
    many researchers in the field."

    I have little doubt that Rob will recognise a reference to EW Dijkstra's "A
    Discipline of Programming" with which Go has a lot in common, but also some
    wide divergences.

    I was surprised that Rob and Russ (can't say I'm as familiar with Ken) did
    not copy the "guarded command" from Dijkstra. But that is now history that
    will have to wait for a second generation of Go to be "corrected". When
    that happens, my hope is that a generic mutex-like operation will also
    become part of the "guard". Sadly, I don't have a sensible proposal, just
    a gut feel that "critical regions" are also missing from Go.

    Just for the record, the above snippet is available from
    http://garfield.library.upenn.edu/classics1988/A1988Q116400001.pdf and is
    referenced as

    Edsger W. Dijkstra
    Department of Computer Sciences
    University of Texas
    Austin, IX 78712-1188
    May 8, 1988

    Lucio.
    On Thursday, 3 September 2015 19:27:01 UTC+2, 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
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Sean Russell at Sep 4, 2015 at 11:54 am

    On Friday, September 4, 2015 at 5:41:08 AM UTC-4, Lucio wrote:
    ...
    I was surprised that Rob and Russ (can't say I'm as familiar with Ken) did
    not copy the "guarded command" from Dijkstra. But that is now history that
    will have to wait for a second generation of Go to be "corrected". When
    that happens, my hope is that a generic mutex-like operation will also
    become part of the "guard". Sadly, I don't have a sensible proposal, just
    a gut feel that "critical regions" are also missing from Go.

    Just for the record, the above snippet is available from
    http://garfield.library.upenn.edu/classics1988/A1988Q116400001.pdf and is
    referenced as
    Thanks for the link Lucio, and I agree that guarded commands improve the
    readability and compactness of code. I really miss them from where they're
    usually found, functional programming languages. I can only speculate that
    they're (relatively) computationally expensive to parse and therefore
    violate the compile-speed goal of Go.

    --- SER

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Skinner at Sep 4, 2015 at 4:06 am
    I did not place the labels because they were needed. I placed them to
    provoke thought regarding the rest of the grammar.

    `for` and `select` are different block types. A `for-select` converges a
    small portion of `for`s functionality with all of `select`. Once you need
    more of `for`, even for just temporal code, you'll need to break it back
    out to `for` and `select`.

    An exception (improvement) was made for `range` in a previous release,
    allowing a `for range` construct, but range can not exist without `for` and
    is in fact nothing more than a clause specific to `for`. This improvement
    made sense since it was about allowing the range clause to be expressed in
    more than one way, much like the `if` and `for` clauses.

    In that sense, there's no precedence to even suggest `for select`. One
    might very well suggest a `for-case` construct such as

    for {
    case <-a:
    case <-b:
    }

    allowing the `for` statement to have either a block or commclause, but
    things get weird quick.
    On Thu, Sep 3, 2015 at 11:48 AM Nick Patavalis wrote:

    On Thursday, September 3, 2015 at 7:41:12 PM UTC+3, Daniel Skinner wrote:

    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    There is no need for such labels with "for select", which is an added
    benefit (I think).

    As I wrote in the previous post:

    - "break" exits the loop (since "for select" is a looping construct)
    - "continue" re-enters the select (again, since "for select" is a looping
    construct)

    /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 golang-nuts+unsubscribe@googlegroups.com.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jérôme Champion at Sep 4, 2015 at 6:43 am
    I don't know if such a rule exist, but I would call it the "Printf rule".
    That is:
      * You should not need to make logical change to your program just to add a
    Printf.

    In that case, if I want to add a Printf in the loop, I have to make change
    to break and continue and that's the kind of case that will certainly cause
    bugs.

    Le jeudi 3 septembre 2015 18:47:21 UTC+2, Nick Patavalis a écrit :
    On Thursday, September 3, 2015 at 7:41:12 PM UTC+3, Daniel Skinner wrote:

    where's the label going to go
    http://play.golang.org/p/uilEREPgIl
    There is no need for such labels with "for select", which is an added
    benefit (I think).

    As I wrote in the previous post:

    - "break" exits the loop (since "for select" is a looping construct)
    - "continue" re-enters the select (again, since "for select" is a looping
    construct)

    /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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • José Colón at Sep 3, 2015 at 5:33 pm
    Just to be clear, adding a for select statement would not eliminate the for
    or the select statements from the language. So if you need the label
    functionality or any other stuff specific to for and select, you would
    still have those.
    On Thursday, September 3, 2015 at 12:41:12 PM UTC-4, Daniel Skinner wrote:

    where's the label going to go
    http://play.golang.org/p/uilEREPgIl

    On Thu, Sep 3, 2015 at 11:06 AM Nick Patavalis <nick.pa...@gmail.com
    <javascript:>> wrote:

    On Thursday, September 3, 2015 at 7:03:13 PM UTC+3, Nick Patavalis wrote:

    but the bar() example above
    I mean the foo() example

    /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 golang-nuts...@googlegroups.com <javascript:>.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Shawn Milochik at Sep 3, 2015 at 5:38 pm
    Let's not forget that, by definition we on this list are programmers.
    Programmers who never tire of telling others how awesome our chosen editor
    is.

    So, you can write macros, plugins, snippets, or whatever to do this easily.
    The very feature of Go this thread is fighting to violate -- its simplicity
    -- is what makes writing these things easier than for other languages.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • José Colón at Sep 3, 2015 at 5:31 pm
    Couldn't gofmt just do this then?

    for select {
         case ...:
         case ...:
         case ...:
    }

    On Thursday, September 3, 2015 at 11:53:32 AM UTC-4, Christian von Kietzell
    wrote:
    Except that now the cases are aligned with for, which looks weird.

    Nick Patavalis <nick.pa...@gmail.com <javascript:>> schrieb am Do., 3.
    Sep. 2015 17:11:
    On Thursday, September 3, 2015 at 6:02:07 PM UTC+3, Christian von
    Kietzell wrote:
    gofmt actually indents case to the same level as select, doesn't it?
    Still, bar() below saves more horizontal space than foo()...

    func foo() {
    for {
    select {
    case a:
    qux()
    case b:
    qux()
    }
    }
    }

    func bar() {
    for select {
    case a:
    qux()
    case b:
    qux()
    }
    }

    /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 golang-nuts...@googlegroups.com <javascript:>.
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 3, '15 at 2:11p
activeSep 4, '15 at 11:54a
posts22
users10
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase