FAQ
Hello gophers,

Reading from the language spec:

For all the cases in the statement, the channel operands of receive
operations and the channel **and right-hand-side expressions of send
statements** are evaluated exactly once, in source order, upon entering the
"select" statement. The result is a set of channels to receive from or send
to, and the corresponding values to send.


I admit, the emphasized part caught me by surprise. Why? I would expect the
right-hand-side part of send statements to be evaluated *only* when the
case selected. This would allow someone to do something like:

case out <- q.Pop():


Now you have to mess with temporary variables and the code gets uglier.

I understand that it is how it is, but I'm wondering, is there any reason
it was chosen to be so?

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

Search Discussions

  • Caleb Spare at Nov 23, 2014 at 7:13 pm
    Quoting Jan Mercl from the
    ​golang-dev
      thread:

    How could the case be selected without evaluating the RHS? Without
    that evaluation it's not known if the communication can proceed, ie.
    if the case could be selected. Very circular it gets ;-)
    ​The RHS of send statements doesn't affect whether the send can proceed;
    only the LHS.
    On Sun, Nov 23, 2014 at 10:52 AM, Nick Patavalis wrote:

    Hello gophers,

    Reading from the language spec:

    For all the cases in the statement, the channel operands of receive
    operations and the channel **and right-hand-side expressions of send
    statements** are evaluated exactly once, in source order, upon entering
    the "select" statement. The result is a set of channels to receive from or
    send to, and the corresponding values to send.


    I admit, the emphasized part caught me by surprise. Why? I would expect
    the right-hand-side part of send statements to be evaluated *only* when the
    case selected. This would allow someone to do something like:

    case out <- q.Pop():


    Now you have to mess with temporary variables and the code gets uglier.

    I understand that it is how it is, but I'm wondering, is there any reason
    it was chosen to be so?

    /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 Nov 23, 2014 at 7:18 pm

    On Sunday, November 23, 2014 9:13:28 PM UTC+2, Caleb Spare wrote:
    Quoting Jan Mercl from the
    ​golang-dev
    thread:

    How could the case be selected without evaluating the RHS? Without
    that evaluation it's not known if the communication can proceed, ie.
    if the case could be selected. Very circular it gets ;-)
    ​The RHS of send statements doesn't affect whether the send can proceed;
    only the LHS.
    That's what I thought to, originally... But now that I'm giving it a second
    thought, what if the RHS contains a blocking call (or, say, a receive
    expression)?

    Yes, I guess that would justify having to evaluate the RHS before deciding
    to select the case...

    /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.
  • Jan Mercl at Nov 23, 2014 at 7:19 pm

    On Sun, Nov 23, 2014 at 8:12 PM, Caleb Spare wrote:
    The RHS of send statements doesn't affect whether the send can proceed; only
    the LHS.
    You're right. I don't know why I was thinking that the RHS is a
    channel receive, sorry.

    -j

    --
    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.
  • Caleb Spare at Nov 23, 2014 at 7:22 pm
    Nick -- while it would make the code nicer, your version of select would
    not allow for as efficient implementations of select+channel operations.
    The channel in question would have to be locked while computing the RHS
    value. Here's an old golang-nuts thread about it:

    https://groups.google.com/d/topic/golang-nuts/qZO4kldyWak/discussion
    On Sun, Nov 23, 2014 at 11:18 AM, Jan Mercl wrote:
    On Sun, Nov 23, 2014 at 8:12 PM, Caleb Spare wrote:
    The RHS of send statements doesn't affect whether the send can proceed; only
    the LHS.
    You're right. I don't know why I was thinking that the RHS is a
    channel receive, sorry.

    -j
    --
    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 Nov 23, 2014 at 7:26 pm

    On Sunday, November 23, 2014 9:22:14 PM UTC+2, Caleb Spare wrote:
    Nick -- while it would make the code nicer, your version of select would
    not allow for as efficient implementations of select+channel operations.
    The channel in question would have to be locked while computing the RHS
    value. Here's an old golang-nuts thread about it:

    https://groups.google.com/d/topic/golang-nuts/qZO4kldyWak/discussion
    Very reasonable, thanks.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 23, '14 at 6:52p
activeNov 23, '14 at 7:26p
posts6
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase