FAQ
I would like to have the keyword "in" as syntactic sugar for ":= range".

So that we could write:

for index, val in slice {
}

instead of

for index, val := range slice {
}



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

  • Ian Taylor at Oct 16, 2014 at 3:28 pm

    On Thu, Oct 16, 2014 at 3:17 AM, wrote:
    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }
    No. Sorry.

    Ian

    --
    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.
  • Dave Cheney at Oct 16, 2014 at 3:46 pm
    Nope, sorry this adds nothing to the language, it merely rearranges the form of the range syntax to be more familiar to some, and less familiar to anyone who's already invested in the exisiting syntax.

    --
    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 Oct 16, 2014 at 3:50 pm

    On Thu, Oct 16, 2014 at 12:17 PM, wrote:
    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }
    The existing syntax allows to either create new, loop scoped variables
    (with :=) or reuse existing, outer scoped ones and that's an important
    feature. The proposal seems to not consider it.

    -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.
  • Jesper Louis Andersen at Oct 16, 2014 at 5:05 pm

    On Thu, Oct 16, 2014 at 5:49 PM, Jan Mercl wrote:

    The existing syntax allows to either create new, loop scoped variables
    (with :=) or reuse existing, outer scoped ones and that's an important
    feature. The proposal seems to not consider it.
    Indeed. It would also seem the existing syntax composes better with other
    functions being introduced later. It would be a shame to close down the
    generalization since it would mean you would have to open the door for
    Python-like special interface names.


    --
    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.
  • Matt Harden at Oct 17, 2014 at 1:55 am
    I agree with Jan, and others in this thread. Clearly the Go authors knew
    about the "in" keyword in other languages, and specifically chose not to
    include it. Range does the job better, without (much) special syntax. While
    I missed "in" at first, now range seems perfectly natural. One thing that
    hasn't been mentioned is how range enables capturing key, value pairs using
    the same multiple-return-value syntax used elsewhere in the language,
    unlike other languages I will refrain from mentioning, which need
    additional functions like keys(), values(), items(), iterkeys(), etc. to
    enable the same functionality.
    On Thu, Oct 16, 2014 at 10:49 AM, Jan Mercl wrote:
    On Thu, Oct 16, 2014 at 12:17 PM, wrote:
    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }
    The existing syntax allows to either create new, loop scoped variables
    (with :=) or reuse existing, outer scoped ones and that's an important
    feature. The proposal seems to not consider it.

    -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.
    --
    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.
  • Chris dollin at Oct 16, 2014 at 3:58 pm

    On 16 October 2014 11:17, wrote:
    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }
    Why?

    `:= range` (and its sibling `= range`) do the job. I don't see the change
    as providing a benefit exceeding the pain of maintaining an extra syntax.

    [Imagines all the questions "what's the difference in using `in` rather
    than `:= range` and the baffled look when we say "there isn't one."]


    Chris "allusive" Dollin

    --
    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.
  • Matt Sherman at Oct 16, 2014 at 4:51 pm
    I've become a fan of sugar being an editor/IDE concern. Give yourself a
    keystroke or snippet that expands in to := range.
    On Thursday, October 16, 2014 6:17:00 AM UTC-4, baruchl...@gmail.com wrote:

    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }


    --
    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.
  • Gerard at Oct 16, 2014 at 5:18 pm
    I could think about the 'in' and 'out' keywords in Ada when used with
    function arguments. That makes sense to me.
    On Thursday, October 16, 2014 12:17:00 PM UTC+2, baruchl...@gmail.com wrote:

    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }


    --
    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.
  • Akwillis at Oct 16, 2014 at 5:19 pm
    I'm not a fan of new symbols, I don't even like the symbols := and <- , but
    that is just me. An example would be that channels could have been updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin library,
    channels are hard coded into the language, making certain issues impossible
    to fix.
    On Thursday, October 16, 2014 6:17:00 AM UTC-4, baruchl...@gmail.com wrote:

    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }


    --
    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.
  • Ian Taylor at Oct 16, 2014 at 5:59 pm

    On Thu, Oct 16, 2014 at 10:19 AM, akwillis wrote:
    I'm not a fan of new symbols, I don't even like the symbols := and <- , but
    that is just me. An example would be that channels could have been updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin library,
    channels are hard coded into the language, making certain issues impossible
    to fix.
    In order for channels to work reasonably, they must be built into the
    language, so that the select statement can work with a reasonable
    syntax.

    Ian

    --
    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.
  • Michael Jones at Oct 16, 2014 at 6:29 pm
    If there was going to be a new keyword or other lexical change (yes, I
    know, not likely) my favorite suggestions of the big debates a few years
    ago were:

    a. "become" which was Ken Thompson's generalized way of tail recursion.

    b. Unicode right and left arrows ("→" and "←") as synonyms for "<-" and
    "->". This is clean and can change no existing program's meaning. (Though
    old Stanford Sail programmers may be confused that it means send/receive
    rather than assignment.)
    On Thu, Oct 16, 2014 at 10:59 AM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 10:19 AM, akwillis wrote:
    I'm not a fan of new symbols, I don't even like the symbols := and <- , but
    that is just me. An example would be that channels could have been updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin library,
    channels are hard coded into the language, making certain issues
    impossible
    to fix.
    In order for channels to work reasonably, they must be built into the
    language, so that the select statement can work with a reasonable
    syntax.

    Ian

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


    --
    *Michael T. Jones | Chief Technology Advocate | mtj@google.com
    <mtj@google.com> | +1 650-335-5765 <%2B1%20650-335-5765>*

    --
    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.
  • Michael Jones at Oct 16, 2014 at 6:45 pm
    oops. no right arrow needed, though I think I remember pushing for tight
    arrow for some reason. don't remember now.
    On Thu, Oct 16, 2014 at 11:29 AM, Michael Jones wrote:

    If there was going to be a new keyword or other lexical change (yes, I
    know, not likely) my favorite suggestions of the big debates a few years
    ago were:

    a. "become" which was Ken Thompson's generalized way of tail recursion.

    b. Unicode right and left arrows ("→" and "←") as synonyms for "<-" and
    "->". This is clean and can change no existing program's meaning. (Though
    old Stanford Sail programmers may be confused that it means send/receive
    rather than assignment.)
    On Thu, Oct 16, 2014 at 10:59 AM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 10:19 AM, akwillis wrote:
    I'm not a fan of new symbols, I don't even like the symbols := and <- , but
    that is just me. An example would be that channels could have been updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin library,
    channels are hard coded into the language, making certain issues
    impossible
    to fix.
    In order for channels to work reasonably, they must be built into the
    language, so that the select statement can work with a reasonable
    syntax.

    Ian

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


    --
    *Michael T. Jones | Chief Technology Advocate | mtj@google.com
    <mtj@google.com> | +1 650-335-5765 <%2B1%20650-335-5765>*


    --
    *Michael T. Jones | Chief Technology Advocate | mtj@google.com
    <mtj@google.com> | +1 650-335-5765*

    --
    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 Oct 16, 2014 at 7:56 pm
    Actually "become" as a keyword originates in Newsqueak.

    -rob

    On Thu, Oct 16, 2014 at 11:44 AM, 'Michael Jones' via golang-nuts wrote:

    oops. no right arrow needed, though I think I remember pushing for tight
    arrow for some reason. don't remember now.
    On Thu, Oct 16, 2014 at 11:29 AM, Michael Jones wrote:

    If there was going to be a new keyword or other lexical change (yes, I
    know, not likely) my favorite suggestions of the big debates a few years
    ago were:

    a. "become" which was Ken Thompson's generalized way of tail recursion.

    b. Unicode right and left arrows ("→" and "←") as synonyms for "<-" and
    "->". This is clean and can change no existing program's meaning. (Though
    old Stanford Sail programmers may be confused that it means send/receive
    rather than assignment.)
    On Thu, Oct 16, 2014 at 10:59 AM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 10:19 AM, akwillis wrote:
    I'm not a fan of new symbols, I don't even like the symbols := and <- , but
    that is just me. An example would be that channels could have been updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin library,
    channels are hard coded into the language, making certain issues
    impossible
    to fix.
    In order for channels to work reasonably, they must be built into the
    language, so that the select statement can work with a reasonable
    syntax.

    Ian

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


    --
    *Michael T. Jones | Chief Technology Advocate | mtj@google.com
    <mtj@google.com> | +1 650-335-5765 <%2B1%20650-335-5765>*


    --
    *Michael T. Jones | Chief Technology Advocate | mtj@google.com
    <mtj@google.com> | +1 650-335-5765 <%2B1%20650-335-5765>*

    --
    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.
  • Bakul Shah at Oct 16, 2014 at 8:02 pm

    On Thu, 16 Oct 2014 12:56:10 PDT Rob Pike wrote:

    Actually "become" as a keyword originates in Newsqueak.
    Scheme doesn't need any keyword to figure out tail recursion.
    -rob

    On Thu, Oct 16, 2014 at 11:29 AM, Michael Jones wrote:

    If there was going to be a new keyword or other lexical change (yes, I
    know, not likely) my favorite suggestions of the big debates a few years
    ago were:

    a. "become" which was Ken Thompson's generalized way of tail recursion.
    --
    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.
  • Ian Taylor at Oct 16, 2014 at 8:05 pm

    On Thu, Oct 16, 2014 at 1:02 PM, Bakul Shah wrote:
    On Thu, 16 Oct 2014 12:56:10 PDT Rob Pike wrote:

    Actually "become" as a keyword originates in Newsqueak.
    Scheme doesn't need any keyword to figure out tail recursion.
    Scheme doesn't give you a way to look at your call stack. Go has
    runtime.Callers, and people use it for purposes other than debugging.
    (I don't know about Newsqueak.)

    Ian

    --
    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 Oct 16, 2014 at 8:13 pm
    Newsqueak flattened its stacks whenever a function returning T "became" a
    call to another function returning T. Newsqueak no return keyword, so in
    this sense it was equivalent to Scheme. State machines were pretty,
    debugging was a little harder.

    -rob

    On Thu, Oct 16, 2014 at 1:05 PM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 1:02 PM, Bakul Shah wrote:
    On Thu, 16 Oct 2014 12:56:10 PDT Rob Pike wrote:

    Actually "become" as a keyword originates in Newsqueak.
    Scheme doesn't need any keyword to figure out tail recursion.
    Scheme doesn't give you a way to look at your call stack. Go has
    runtime.Callers, and people use it for purposes other than debugging.
    (I don't know about Newsqueak.)

    Ian
    --
    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.
  • Bakul Shah at Oct 16, 2014 at 8:32 pm

    On Thu, 16 Oct 2014 13:05:50 PDT Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 1:02 PM, Bakul Shah wrote:
    On Thu, 16 Oct 2014 12:56:10 PDT Rob Pike wrote:

    Actually "become" as a keyword originates in Newsqueak.
    Scheme doesn't need any keyword to figure out tail recursion.
    Scheme doesn't give you a way to look at your call stack. Go has
    runtime.Callers, and people use it for purposes other than debugging.
    Ah. In that case it seems "become" would be only useful as a
    low level performance hack.

    Tail recursion probably has not much of a win for Go in any case.

    --
    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.
  • Matt Harden at Oct 17, 2014 at 12:21 am
    "Must" is a strong word. It could have been done with just another special
    function like make and append.

    select(
       c1, func(i int) { println(i, "came from c1") },
       c2, func(s string) { println(s, "came from c2") },
       c3, func() bool { println("Sending true on c3"); return true},
    )

    The syntactic sugar of the current select statement is nice of course, but
    the above syntax isn't so bad IMO. The function could be implemented today
    using reflect.Select. Go can't typecheck it, but that would be easier to
    add to the hypothetical language "Go minus channels" than first class
    channels would be.

    On Thu, Oct 16, 2014 at 12:59 PM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 10:19 AM, akwillis wrote:
    I'm not a fan of new symbols, I don't even like the symbols := and <- , but
    that is just me. An example would be that channels could have been updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin library,
    channels are hard coded into the language, making certain issues
    impossible
    to fix.
    In order for channels to work reasonably, they must be built into the
    language, so that the select statement can work with a reasonable
    syntax.

    Ian

    --
    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.
  • Andrey mirtchovski at Oct 17, 2014 at 1:04 am

    The syntactic sugar of the current select statement is nice of course, but
    the above syntax isn't so bad IMO. The function could be implemented today
    using reflect.Select. Go can't typecheck it, but that would be easier to add
    to the hypothetical language "Go minus channels" than first class channels
    would be.
    some of the authors of Go have spent considerable time dealing with "X
    minus channels". for an example see the "Alt" construct from Plan 9's
    libthread: http://plan9.bell-labs.com/magic/man2html/2/thread

    limbo's "alt"[1] is comparatively much nicer and the step to select {}
    is much smaller after that.

    --
    1: http://www.vitanuova.com/inferno/papers/limbo.html, section 9.8

    --
    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.
  • Matt Harden at Oct 17, 2014 at 1:44 am

    On Thu, Oct 16, 2014 at 8:04 PM, andrey mirtchovski wrote:
    some of the authors of Go have spent considerable time dealing with "X
    minus channels". for an example see the "Alt" construct from Plan 9's
    libthread: http://plan9.bell-labs.com/magic/man2html/2/thread

    If you're trying to explain to me why the Go authors included first class
    channels, I already know the history and I'm not at all suggesting the
    language would be better without them. I was merely responding to the
    statement by Ian Taylor that channels "must" be built in to the language in
    order for select to have a reasonable syntax.

    If you're suggesting that libthread's Alt struct is comparable to the
    select function I presented, I definitely don't agree with that. However
    it's hard to do better in C, unlike in [Go minus channels].

    Anyway this discussion is a digression from the thread's topic.

    --
    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.
  • Jesse McNelis at Oct 17, 2014 at 3:28 am

    On Fri, Oct 17, 2014 at 12:44 PM, Matt Harden wrote:
    If you're trying to explain to me why the Go authors included first class
    channels, I already know the history and I'm not at all suggesting the
    language would be better without them. I was merely responding to the
    statement by Ian Taylor that channels "must" be built in to the language in
    order for select to have a reasonable syntax.
    I've done enough nodejs to know that replacing blocks with functions
    is generally horrible.
    You lose the ability to use 'break', 'continue', 'goto', 'return'. To
    get values out of the functions you have to assign them to variables
    from the outside scope and then use that state to figure out which
    function got called so you know what do do with those values after the
    select.

    --
    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.
  • Ian Taylor at Oct 17, 2014 at 5:12 am

    On Thu, Oct 16, 2014 at 5:21 PM, Matt Harden wrote:
    "Must" is a strong word. It could have been done with just another special
    function like make and append.

    select(
    c1, func(i int) { println(i, "came from c1") },
    c2, func(s string) { println(s, "came from c2") },
    c3, func() bool { println("Sending true on c3"); return true},
    )

    The syntactic sugar of the current select statement is nice of course, but
    the above syntax isn't so bad IMO.
    That's interesting but I don't find it convincing.

    I'm sticking with "must."

    Ian

    On Thu, Oct 16, 2014 at 12:59 PM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 10:19 AM, akwillis wrote:
    I'm not a fan of new symbols, I don't even like the symbols := and <- ,
    but
    that is just me. An example would be that channels could have been
    updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin
    library,
    channels are hard coded into the language, making certain issues
    impossible
    to fix.
    In order for channels to work reasonably, they must be built into the
    language, so that the select statement can work with a reasonable
    syntax.

    Ian

    --
    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.
  • Matt Harden at Oct 20, 2014 at 12:01 pm
    From a practical point of view, "must" may be correct. From a theoretical
    point of view, I don't think special syntax is necessary to make channels
    usable. Go is a practical language. Therefore, I concede the point. :-)
    On Fri, Oct 17, 2014 at 12:12 AM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 5:21 PM, Matt Harden wrote:

    "Must" is a strong word. It could have been done with just another special
    function like make and append.

    select(
    c1, func(i int) { println(i, "came from c1") },
    c2, func(s string) { println(s, "came from c2") },
    c3, func() bool { println("Sending true on c3"); return true},
    )

    The syntactic sugar of the current select statement is nice of course, but
    the above syntax isn't so bad IMO.
    That's interesting but I don't find it convincing.

    I'm sticking with "must."

    Ian

    On Thu, Oct 16, 2014 at 12:59 PM, Ian Taylor wrote:
    On Thu, Oct 16, 2014 at 10:19 AM, akwillis wrote:
    I'm not a fan of new symbols, I don't even like the symbols := and <-
    ,
    but
    that is just me. An example would be that channels could have been
    updated
    with new methods that operated differently to fix the perceived flaws
    without breaking go 1 guarantee. Instead of just being a builtin
    library,
    channels are hard coded into the language, making certain issues
    impossible
    to fix.
    In order for channels to work reasonably, they must be built into the
    language, so that the select statement can work with a reasonable
    syntax.

    Ian

    --
    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.
  • Jesse McNelis at Oct 20, 2014 at 1:43 pm

    On Mon, Oct 20, 2014 at 11:01 PM, Matt Harden wrote:
    From a practical point of view, "must" may be correct. From a theoretical
    point of view, I don't think special syntax is necessary to make channels
    usable. Go is a practical language. Therefore, I concede the point. :-)
    From a theoretical point of view you could replace most of the
    keywords and syntax in Go with just functions that take function
    parameters....but then you'd have a lisp.

    --
    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.
  • Harts Antler at Oct 20, 2014 at 1:14 pm
    If you want more python like syntax in Go, then Gython is what you need. It
    supports enumerate loops, and `for key,value in map` loops.
    https://github.com/gython/Gython

    On Thursday, October 16, 2014 3:17:00 AM UTC-7, baruchl...@gmail.com wrote:

    I would like to have the keyword "in" as syntactic sugar for ":= range".

    So that we could write:

    for index, val in slice {
    }

    instead of

    for index, val := range slice {
    }


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

People

Translate

site design / logo © 2022 Grokbase