FAQ
What is the rationale for the ++ and -- operators as syntactic sugar for
+=1 and -=1 respectively?

Does this not introduce unnecessary choices and make it difficult to
simplify statements such as:

a++
b++

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

Search Discussions

  • Jan Mercl at Feb 13, 2013 at 12:52 pm

    On Wed, Feb 13, 2013 at 1:25 PM, Starfish wrote:
    What is the rationale for the ++ and -- operators as syntactic sugar for +=1
    and -=1 respectively?
    I guess b/c `a++` is half the characters of `a += 1`
    Does this not introduce unnecessary choices and make it difficult to
    simplify statements such as:

    a++
    b++
    Here you lost me. What simplification of `a++`, beyond the single CPU
    instruction produced by many compilers, is to be expected?

    -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/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 13, 2013 at 1:01 pm
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly about it.

    On Wed, Feb 13, 2013 at 1:52 PM, Jan Mercl wrote:
    On Wed, Feb 13, 2013 at 1:25 PM, Starfish wrote:
    What is the rationale for the ++ and -- operators as syntactic sugar for +=1
    and -=1 respectively?
    I guess b/c `a++` is half the characters of `a += 1`
    Does this not introduce unnecessary choices and make it difficult to
    simplify statements such as:

    a++
    b++
    Here you lost me. What simplification of `a++`, beyond the single CPU
    instruction produced by many compilers, is to be expected?

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

    --
    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/groups/opt_out.
  • Jan Mercl at Feb 13, 2013 at 1:04 pm

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly about it.
    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

    -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/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 13, 2013 at 1:06 pm
    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.

    On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
    wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly about
    it.

    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

    -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/groups/opt_out.
  • Jan Mercl at Feb 13, 2013 at 1:37 pm

    On Wed, Feb 13, 2013 at 2:06 PM, Patrick Mylund Nielsen wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.
    Why should non programmers read Go source code?

    -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/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 13, 2013 at 1:42 pm
    Python doesn't have ++ or --, and somehow it manages to be a programming
    language.

    On Wed, Feb 13, 2013 at 2:37 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:06 PM, Patrick Mylund Nielsen
    wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.
    Why should non programmers read Go source code?

    -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/groups/opt_out.
  • Chris dollin at Feb 13, 2013 at 1:46 pm

    On 13 February 2013 13:37, Jan Mercl wrote:
    On Wed, Feb 13, 2013 at 2:06 PM, Patrick Mylund Nielsen
    wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.
    Why should non programmers read Go source code?
    You don't have to be a non-programmer to not know a C-like
    language: there are plenty of them out there, and sometimes
    they are someone's first language.

    Chris

    Common Lisp, Scheme, Prolog, Standard ML, Pop11, Pascal,
    Basic, Smalltalk ...

    --
    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/groups/opt_out.
  • Jan Mercl at Feb 13, 2013 at 2:04 pm

    On Wed, Feb 13, 2013 at 2:46 PM, chris dollin wrote:
    You don't have to be a non-programmer to not know a C-like
    language: there are plenty of them out there, and sometimes
    they are someone's first language.
    Impossible, can't be true. Every _programmer_ must know C. Q.E.D.

    -j

    PS: Yeah, I deserve whatever comes next ;-)

    --
    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/groups/opt_out.
  • Gustavo Niemeyer at Feb 13, 2013 at 1:38 pm

    On Wed, Feb 13, 2013 at 11:06 AM, Patrick Mylund Nielsen wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.
    I could argue about the delta of intuitiveness of "+=" vs. "++" to
    heat up that conversation, but really.. this is a done deal, and a
    pretty insignificant one. Let's all go coding.


    gustavo @ http://niemeyer.net

    --
    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/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 13, 2013 at 1:46 pm
    Completely agree. I responded because these knee-jerk responses that all
    the choices Go have made are perfect because <insert a fitting argument
    that contradicts a basic tenent of the language> are annoying. Starfish
    asked what the rationale was, not for the language to be changed.

    So far the rationale seems to be that Ken likes ++. That's fine. Just don't
    try to sell it as something different.

    On Wed, Feb 13, 2013 at 2:38 PM, Gustavo Niemeyer wrote:

    On Wed, Feb 13, 2013 at 11:06 AM, Patrick Mylund Nielsen
    wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.
    I could argue about the delta of intuitiveness of "+=" vs. "++" to
    heat up that conversation, but really.. this is a done deal, and a
    pretty insignificant one. Let's all go coding.


    gustavo @ http://niemeyer.net
    --
    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/groups/opt_out.
  • Kevin Gillette at Feb 13, 2013 at 6:08 pm
    A great many languages have increment/decrement operators, many with c++ semantics (it's an expression, prefixed use allowed). Javascript it's one example of this, and since js has a monopoly on browser-based programming, anyone wanting programmatic access to that medium will eventually notice ”++” anyway. Go compilers will quickly and thoroughly teach the semantic difference.

    Anyway, I've encountered many languages which don't have += style constructs, or c-style character escaping in strings, or even any concept of mutable variables. go was, not surprisingly, designed to not be particularly surprising to c programmers, and it's not possible to be unsurprising to everyone. C is arguably the dominant reference language for the ”imperative” programming paradigm, and it's semantics are (at least indirectly) well known to a great many programmers -- since go follows the same overarching paradigm, it's reasonable the language family's greatest common denominator is used as the conceptual base for its core imperative 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/groups/opt_out.
  • Michael Jones at Feb 13, 2013 at 7:39 pm
    The axiomatic development of number systems, "natural numbers" and integers
    in particular, depends on the idea of a successor for each number. This
    means that many people will have a natural understanding of the concept.

    Integral types in the C-family have n++ as the "become the successor"
    function for n, and n-- as the "become the predecessor" for n. Pascal and
    Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
    is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
    when advancing through enumerant values.) When I see ++ I always read
    "next" and likewise "previous" or "prior" for --. It made sense to me from
    day one of C.

    The operator_equal functions in C are more natural than the plain equal to
    one who has studied, designed, or built computers, as well as one who
    programs actual computers rather than the virtualized conception of
    computers suggested by high-level languages.

    If a, b, and c are in memory, is there a computer in use today that can
    compute a=b+c where the operands come from memory and the result goes to
    memory? Is there one that can compute b+c where the operands come from
    memory and the result goes to a register? This is certainly not likely.
    Instead, actual computers can do either of the following:

    r0 = load b
    r1 = load c
    r2 = r0 + r1 // aka, r2 = r0 + r1
    a = store r2

    or

    r0 = load b
    r1 = load c
    r0 = r0 + r1 // aka, r0 += r1
    a = store r0

    If you've dealt with this, and learned to do the second "+=" version
    wherever possible to accomplish more with a limited supply of registers,
    then the idea of "+=" in a high-level language a pleasing window into the
    soul of the machine. In olden times, there was one register, the
    accumulator, and all the operations were of the operator_equals variety. In
    modern times, there are many registers, and fancy compilers do everything
    they can to save registers in just this way.

    It is also a practical aid to comprehension. Just this morning I wrote this:

    func (p *Plan) ClearZero(length, sum, residue int) {
    index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
    mask := uint64(1) << uint(residue&0x3f) // residue%64
    p.zero[index] &^= mask // tuple known to
    be zero
    }

    Personally, I like find it simpler as written than would be:

    p.zero[index] = p.zero[index] &^ mask

    Because (a) it's telling me that the left hand side value is being updated
    in place so I don't have to look closely to see that the two array indices
    are the same, it's shouting to the compiler to use the same address for the
    load and store. It's also the "half of the compiler's optimizations are in
    the developer's source code" mindset that several on the Go team believe.
    Imagine the ugly and expanded case:

    p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] =
    p.zero[(length*(p.sum+1)+sum)*p.words
    + (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

    There are many cases where a compiler gets this as input. It has to deduce
    that the LHS index and the RHS indices are common expressions, that the
    slices are the same, and so that the same address can be used for bounds
    check, load, and store, that only one bounds check is needed, and so on.
    Optimizing compilers do this, but imperfectly at times and slowly as well.
    The "+=" style helps hugely here because all the things that need to be
    understood are as clear for the compiler as they are for the programmer.

    One of my favorite things about C, perhaps my favorite thing, is that it
    embraces the true nature of computers. My least favorite thing about it is
    the other side of this same truth--it embraces and exposes a tiny subset of
    the true nature of computers (the "greatest hits" say) and leaves the rest
    out. This makes programs less efficient than they could be and worst,
    discourages CPU designers from extending computers in ways they otherwise
    might.
    On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette wrote:
    A great many languages have increment/decrement operators, many with c++
    semantics (it's an expression, prefixed use allowed). Javascript it's one
    example of this, and since js has a monopoly on browser-based programming,
    anyone wanting programmatic access to that medium will eventually notice
    ”++” anyway. Go compilers will quickly and thoroughly teach the semantic
    difference.
    Anyway, I've encountered many languages which don't have += style
    constructs, or c-style character escaping in strings, or even any concept
    of mutable variables. go was, not surprisingly, designed to not be
    particularly surprising to c programmers, and it's not possible to be
    unsurprising to everyone. C is arguably the dominant reference language for
    the ”imperative” programming paradigm, and it's semantics are (at least
    indirectly) well known to a great many programmers -- since go follows the
    same overarching paradigm, it's reasonable the language family's greatest
    common denominator is used as the conceptual base for its core imperative
    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/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | 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/groups/opt_out.
  • Peter at Feb 13, 2013 at 9:16 pm
    Does the compiler optimise

    x % 64

    into

    x & 63

    ?

    (Then you wouldn't need the comments.)
    On Wednesday, 13 February 2013 19:38:33 UTC, Michael Jones wrote:

    The axiomatic development of number systems, "natural numbers" and
    integers in particular, depends on the idea of a successor for each number.
    This means that many people will have a natural understanding of the
    concept.

    Integral types in the C-family have n++ as the "become the successor"
    function for n, and n-- as the "become the predecessor" for n. Pascal and
    Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
    is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
    when advancing through enumerant values.) When I see ++ I always read
    "next" and likewise "previous" or "prior" for --. It made sense to me from
    day one of C.

    The operator_equal functions in C are more natural than the plain equal to
    one who has studied, designed, or built computers, as well as one who
    programs actual computers rather than the virtualized conception of
    computers suggested by high-level languages.

    If a, b, and c are in memory, is there a computer in use today that can
    compute a=b+c where the operands come from memory and the result goes to
    memory? Is there one that can compute b+c where the operands come from
    memory and the result goes to a register? This is certainly not likely.
    Instead, actual computers can do either of the following:

    r0 = load b
    r1 = load c
    r2 = r0 + r1 // aka, r2 = r0 + r1
    a = store r2

    or

    r0 = load b
    r1 = load c
    r0 = r0 + r1 // aka, r0 += r1
    a = store r0

    If you've dealt with this, and learned to do the second "+=" version
    wherever possible to accomplish more with a limited supply of registers,
    then the idea of "+=" in a high-level language a pleasing window into the
    soul of the machine. In olden times, there was one register, the
    accumulator, and all the operations were of the operator_equals variety. In
    modern times, there are many registers, and fancy compilers do everything
    they can to save registers in just this way.

    It is also a practical aid to comprehension. Just this morning I wrote
    this:

    func (p *Plan) ClearZero(length, sum, residue int) {
    index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
    mask := uint64(1) << uint(residue&0x3f) // residue%64
    p.zero[index] &^= mask // tuple known
    to be zero
    }

    Personally, I like find it simpler as written than would be:

    p.zero[index] = p.zero[index] &^ mask

    Because (a) it's telling me that the left hand side value is being updated
    in place so I don't have to look closely to see that the two array indices
    are the same, it's shouting to the compiler to use the same address for the
    load and store. It's also the "half of the compiler's optimizations are in
    the developer's source code" mindset that several on the Go team believe.
    Imagine the ugly and expanded case:

    p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] = p.zero[(length*(p.sum+1)+sum)*p.words
    + (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

    There are many cases where a compiler gets this as input. It has to deduce
    that the LHS index and the RHS indices are common expressions, that the
    slices are the same, and so that the same address can be used for bounds
    check, load, and store, that only one bounds check is needed, and so on.
    Optimizing compilers do this, but imperfectly at times and slowly as well.
    The "+=" style helps hugely here because all the things that need to be
    understood are as clear for the compiler as they are for the programmer.

    One of my favorite things about C, perhaps my favorite thing, is that it
    embraces the true nature of computers. My least favorite thing about it is
    the other side of this same truth--it embraces and exposes a tiny subset of
    the true nature of computers (the "greatest hits" say) and leaves the rest
    out. This makes programs less efficient than they could be and worst,
    discourages CPU designers from extending computers in ways they otherwise
    might.
    On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette wrote:
    A great many languages have increment/decrement operators, many with c++
    semantics (it's an expression, prefixed use allowed). Javascript it's one
    example of this, and since js has a monopoly on browser-based programming,
    anyone wanting programmatic access to that medium will eventually notice
    ”++” anyway. Go compilers will quickly and thoroughly teach the semantic
    difference.
    Anyway, I've encountered many languages which don't have += style
    constructs, or c-style character escaping in strings, or even any concept
    of mutable variables. go was, not surprisingly, designed to not be
    particularly surprising to c programmers, and it's not possible to be
    unsurprising to everyone. C is arguably the dominant reference language for
    the ”imperative” programming paradigm, and it's semantics are (at least
    indirectly) well known to a great many programmers -- since go follows the
    same overarching paradigm, it's reasonable the language family's greatest
    common denominator is used as the conceptual base for its core imperative
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>| +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/groups/opt_out.
  • Peter at Feb 13, 2013 at 9:23 pm
    On checking the spec, no - since x is signed.
    http://golang.org/ref/spec#Arithmetic_operators

    If the dividend is positive and the divisor is a constant power of 2, the
    division may be replaced by a right shift, and computing the remainder may
    be replaced by a bitwise "and" operation:
    On Wednesday, 13 February 2013 21:16:47 UTC, Peter wrote:

    Does the compiler optimise

    x % 64

    into

    x & 63

    ?

    (Then you wouldn't need the comments.)
    On Wednesday, 13 February 2013 19:38:33 UTC, Michael Jones wrote:

    The axiomatic development of number systems, "natural numbers" and
    integers in particular, depends on the idea of a successor for each number.
    This means that many people will have a natural understanding of the
    concept.

    Integral types in the C-family have n++ as the "become the successor"
    function for n, and n-- as the "become the predecessor" for n. Pascal and
    Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
    is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
    when advancing through enumerant values.) When I see ++ I always read
    "next" and likewise "previous" or "prior" for --. It made sense to me from
    day one of C.

    The operator_equal functions in C are more natural than the plain equal
    to one who has studied, designed, or built computers, as well as one who
    programs actual computers rather than the virtualized conception of
    computers suggested by high-level languages.

    If a, b, and c are in memory, is there a computer in use today that can
    compute a=b+c where the operands come from memory and the result goes to
    memory? Is there one that can compute b+c where the operands come from
    memory and the result goes to a register? This is certainly not likely.
    Instead, actual computers can do either of the following:

    r0 = load b
    r1 = load c
    r2 = r0 + r1 // aka, r2 = r0 + r1
    a = store r2

    or

    r0 = load b
    r1 = load c
    r0 = r0 + r1 // aka, r0 += r1
    a = store r0

    If you've dealt with this, and learned to do the second "+=" version
    wherever possible to accomplish more with a limited supply of registers,
    then the idea of "+=" in a high-level language a pleasing window into the
    soul of the machine. In olden times, there was one register, the
    accumulator, and all the operations were of the operator_equals variety. In
    modern times, there are many registers, and fancy compilers do everything
    they can to save registers in just this way.

    It is also a practical aid to comprehension. Just this morning I wrote
    this:

    func (p *Plan) ClearZero(length, sum, residue int) {
    index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
    mask := uint64(1) << uint(residue&0x3f) // residue%64
    p.zero[index] &^= mask // tuple known
    to be zero
    }

    Personally, I like find it simpler as written than would be:

    p.zero[index] = p.zero[index] &^ mask

    Because (a) it's telling me that the left hand side value is being
    updated in place so I don't have to look closely to see that the two array
    indices are the same, it's shouting to the compiler to use the same address
    for the load and store. It's also the "half of the
    compiler's optimizations are in the developer's source code" mindset that
    several on the Go team believe. Imagine the ugly and expanded case:

    p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] = p.zero[(length*(p.sum+1)+sum)*p.words
    + (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

    There are many cases where a compiler gets this as input. It has to
    deduce that the LHS index and the RHS indices are common expressions, that
    the slices are the same, and so that the same address can be used for
    bounds check, load, and store, that only one bounds check is needed, and so
    on. Optimizing compilers do this, but imperfectly at times and slowly as
    well. The "+=" style helps hugely here because all the things that need to
    be understood are as clear for the compiler as they are for the programmer.

    One of my favorite things about C, perhaps my favorite thing, is that it
    embraces the true nature of computers. My least favorite thing about it is
    the other side of this same truth--it embraces and exposes a tiny subset of
    the true nature of computers (the "greatest hits" say) and leaves the rest
    out. This makes programs less efficient than they could be and worst,
    discourages CPU designers from extending computers in ways they otherwise
    might.

    On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette <extempor...@gmail.com>
    wrote:
    A great many languages have increment/decrement operators, many with
    c++ semantics (it's an expression, prefixed use allowed). Javascript it's
    one example of this, and since js has a monopoly on browser-based
    programming, anyone wanting programmatic access to that medium will
    eventually notice ”++” anyway. Go compilers will quickly and thoroughly
    teach the semantic difference.
    Anyway, I've encountered many languages which don't have += style
    constructs, or c-style character escaping in strings, or even any concept
    of mutable variables. go was, not surprisingly, designed to not be
    particularly surprising to c programmers, and it's not possible to be
    unsurprising to everyone. C is arguably the dominant reference language for
    the ”imperative” programming paradigm, and it's semantics are (at least
    indirectly) well known to a great many programmers -- since go follows the
    same overarching paradigm, it's reasonable the language family's greatest
    common denominator is used as the conceptual base for its core imperative
    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...@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | m...@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/groups/opt_out.
  • Rob Pike at Feb 13, 2013 at 9:24 pm

    On Wed, Feb 13, 2013 at 1:16 PM, Peter wrote:
    Does the compiler optimise

    x % 64

    into

    x & 63
    I hope not, because that is incorrect if x is negative.

    -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/groups/opt_out.
  • Michael Jones at Feb 13, 2013 at 9:39 pm
    No, for the reason Rob states. My values are all >0, so it works for me,
    but doing all the casts is just too ugly and having the parameter be of
    type uint64 pushes the cast-contamination issue to the callers...
    On Wed, Feb 13, 2013 at 1:24 PM, Rob Pike wrote:
    On Wed, Feb 13, 2013 at 1:16 PM, Peter wrote:
    Does the compiler optimise

    x % 64

    into

    x & 63
    I hope not, because that is incorrect if x is negative.

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


    --
    Michael T. Jones | Chief Technology Advocate | 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/groups/opt_out.
  • peterGo at Feb 14, 2013 at 10:31 pm
    Michael,

    "If a, b, and c are in memory, is there a computer in use today that can
    compute a=b+c where the operands come from memory and the result goes to
    memory? . . . This is certainly not likely."

    Yes. Using IBM mainframe Assembler machine language SS instructions,

    ZAP a,b
    AP a,c

    IBM z/Architecture Reference Summary, Eighth Edition (September, 2012),
    SA22-7871-07.

    Peter
    On Wednesday, February 13, 2013 2:38:33 PM UTC-5, Michael Jones wrote:

    The axiomatic development of number systems, "natural numbers" and
    integers in particular, depends on the idea of a successor for each number.
    This means that many people will have a natural understanding of the
    concept.

    Integral types in the C-family have n++ as the "become the successor"
    function for n, and n-- as the "become the predecessor" for n. Pascal and
    Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
    is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
    when advancing through enumerant values.) When I see ++ I always read
    "next" and likewise "previous" or "prior" for --. It made sense to me from
    day one of C.

    The operator_equal functions in C are more natural than the plain equal to
    one who has studied, designed, or built computers, as well as one who
    programs actual computers rather than the virtualized conception of
    computers suggested by high-level languages.

    If a, b, and c are in memory, is there a computer in use today that can
    compute a=b+c where the operands come from memory and the result goes to
    memory? Is there one that can compute b+c where the operands come from
    memory and the result goes to a register? This is certainly not likely.
    Instead, actual computers can do either of the following:

    r0 = load b
    r1 = load c
    r2 = r0 + r1 // aka, r2 = r0 + r1
    a = store r2

    or

    r0 = load b
    r1 = load c
    r0 = r0 + r1 // aka, r0 += r1
    a = store r0

    If you've dealt with this, and learned to do the second "+=" version
    wherever possible to accomplish more with a limited supply of registers,
    then the idea of "+=" in a high-level language a pleasing window into the
    soul of the machine. In olden times, there was one register, the
    accumulator, and all the operations were of the operator_equals variety. In
    modern times, there are many registers, and fancy compilers do everything
    they can to save registers in just this way.

    It is also a practical aid to comprehension. Just this morning I wrote
    this:

    func (p *Plan) ClearZero(length, sum, residue int) {
    index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
    mask := uint64(1) << uint(residue&0x3f) // residue%64
    p.zero[index] &^= mask // tuple known
    to be zero
    }

    Personally, I like find it simpler as written than would be:

    p.zero[index] = p.zero[index] &^ mask

    Because (a) it's telling me that the left hand side value is being updated
    in place so I don't have to look closely to see that the two array indices
    are the same, it's shouting to the compiler to use the same address for the
    load and store. It's also the "half of the compiler's optimizations are in
    the developer's source code" mindset that several on the Go team believe.
    Imagine the ugly and expanded case:

    p.zero[(length*(p.sum+1)+sum)*p.words + (residue >> 6)] = p.zero[(length*(p.sum+1)+sum)*p.words
    + (residue >> 6)] &^ uint64(1) << uint(residue&0x3f)

    There are many cases where a compiler gets this as input. It has to deduce
    that the LHS index and the RHS indices are common expressions, that the
    slices are the same, and so that the same address can be used for bounds
    check, load, and store, that only one bounds check is needed, and so on.
    Optimizing compilers do this, but imperfectly at times and slowly as well.
    The "+=" style helps hugely here because all the things that need to be
    understood are as clear for the compiler as they are for the programmer.

    One of my favorite things about C, perhaps my favorite thing, is that it
    embraces the true nature of computers. My least favorite thing about it is
    the other side of this same truth--it embraces and exposes a tiny subset of
    the true nature of computers (the "greatest hits" say) and leaves the rest
    out. This makes programs less efficient than they could be and worst,
    discourages CPU designers from extending computers in ways they otherwise
    might.
    On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette wrote:
    A great many languages have increment/decrement operators, many with c++
    semantics (it's an expression, prefixed use allowed). Javascript it's one
    example of this, and since js has a monopoly on browser-based programming,
    anyone wanting programmatic access to that medium will eventually notice
    ”++” anyway. Go compilers will quickly and thoroughly teach the semantic
    difference.
    Anyway, I've encountered many languages which don't have += style
    constructs, or c-style character escaping in strings, or even any concept
    of mutable variables. go was, not surprisingly, designed to not be
    particularly surprising to c programmers, and it's not possible to be
    unsurprising to everyone. C is arguably the dominant reference language for
    the ”imperative” programming paradigm, and it's semantics are (at least
    indirectly) well known to a great many programmers -- since go follows the
    same overarching paradigm, it's reasonable the language family's greatest
    common denominator is used as the conceptual base for its core imperative
    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...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.


    --
    Michael T. Jones | Chief Technology Advocate | m...@google.com<javascript:>| +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/groups/opt_out.
  • Michael Jones at Feb 14, 2013 at 10:37 pm
    Ha! I knew there would a counter example. Thanks! The DEC VAX could too...
    and arguably the TI CPUs.
    On Feb 14, 2013 2:31 PM, "peterGo" wrote:

    Michael,

    "If a, b, and c are in memory, is there a computer in use today that can
    compute a=b+c where the operands come from memory and the result goes to
    memory? . . . This is certainly not likely."

    Yes. Using IBM mainframe Assembler machine language SS instructions,

    ZAP a,b
    AP a,c

    IBM z/Architecture Reference Summary, Eighth Edition (September, 2012),
    SA22-7871-07.

    Peter
    On Wednesday, February 13, 2013 2:38:33 PM UTC-5, Michael Jones wrote:

    The axiomatic development of number systems, "natural numbers" and
    integers in particular, depends on the idea of a successor for each number.
    This means that many people will have a natural understanding of the
    concept.

    Integral types in the C-family have n++ as the "become the successor"
    function for n, and n-- as the "become the predecessor" for n. Pascal and
    Ada have SUCC(n) for the successor and PRED(n) for the predecessor (which
    is n+1 and n-1 respectively, but is more sophisticated in Ada and Pascal
    when advancing through enumerant values.) When I see ++ I always read
    "next" and likewise "previous" or "prior" for --. It made sense to me from
    day one of C.

    The operator_equal functions in C are more natural than the plain equal
    to one who has studied, designed, or built computers, as well as one who
    programs actual computers rather than the virtualized conception of
    computers suggested by high-level languages.

    If a, b, and c are in memory, is there a computer in use today that can
    compute a=b+c where the operands come from memory and the result goes to
    memory? Is there one that can compute b+c where the operands come from
    memory and the result goes to a register? This is certainly not likely.
    Instead, actual computers can do either of the following:

    r0 = load b
    r1 = load c
    r2 = r0 + r1 // aka, r2 = r0 + r1
    a = store r2

    or

    r0 = load b
    r1 = load c
    r0 = r0 + r1 // aka, r0 += r1
    a = store r0

    If you've dealt with this, and learned to do the second "+=" version
    wherever possible to accomplish more with a limited supply of registers,
    then the idea of "+=" in a high-level language a pleasing window into the
    soul of the machine. In olden times, there was one register, the
    accumulator, and all the operations were of the operator_equals variety. In
    modern times, there are many registers, and fancy compilers do everything
    they can to save registers in just this way.

    It is also a practical aid to comprehension. Just this morning I wrote
    this:

    func (p *Plan) ClearZero(length, sum, residue int) {
    index := (length*(p.sum+1)+sum)*p.words + (residue >> 6) // residue/64
    mask := uint64(1) << uint(residue&0x3f) // residue%64
    p.zero[index] &^= mask // tuple known
    to be zero
    }

    Personally, I like find it simpler as written than would be:

    p.zero[index] = p.zero[index] &^ mask

    Because (a) it's telling me that the left hand side value is being
    updated in place so I don't have to look closely to see that the two array
    indices are the same, it's shouting to the compiler to use the same address
    for the load and store. It's also the "half of the
    compiler's optimizations are in the developer's source code" mindset that
    several on the Go team believe. Imagine the ugly and expanded case:

    p.zero[(length*(p.sum+1)+sum)***p.words + (residue >> 6)] = p.zero[
    (length*(p.sum+1)+**sum)*p.words + (residue >> 6)] &^ uint64(1) <<
    uint(residue&0x3f)

    There are many cases where a compiler gets this as input. It has to
    deduce that the LHS index and the RHS indices are common expressions, that
    the slices are the same, and so that the same address can be used for
    bounds check, load, and store, that only one bounds check is needed, and so
    on. Optimizing compilers do this, but imperfectly at times and slowly as
    well. The "+=" style helps hugely here because all the things that need to
    be understood are as clear for the compiler as they are for the programmer.

    One of my favorite things about C, perhaps my favorite thing, is that it
    embraces the true nature of computers. My least favorite thing about it is
    the other side of this same truth--it embraces and exposes a tiny subset of
    the true nature of computers (the "greatest hits" say) and leaves the rest
    out. This makes programs less efficient than they could be and worst,
    discourages CPU designers from extending computers in ways they otherwise
    might.

    On Wed, Feb 13, 2013 at 10:08 AM, Kevin Gillette <extempor...@gmail.com>
    wrote:
    A great many languages have increment/decrement operators, many with
    c++ semantics (it's an expression, prefixed use allowed). Javascript it's
    one example of this, and since js has a monopoly on browser-based
    programming, anyone wanting programmatic access to that medium will
    eventually notice ”++” anyway. Go compilers will quickly and thoroughly
    teach the semantic difference.
    Anyway, I've encountered many languages which don't have += style
    constructs, or c-style character escaping in strings, or even any concept
    of mutable variables. go was, not surprisingly, designed to not be
    particularly surprising to c programmers, and it's not possible to be
    unsurprising to everyone. C is arguably the dominant reference language for
    the ”imperative” programming paradigm, and it's semantics are (at least
    indirectly) well known to a great many programmers -- since go follows the
    same overarching paradigm, it's reasonable the language family's greatest
    common denominator is used as the conceptual base for its core imperative
    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...@**googlegroups.com.
    For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
    .


    --
    Michael T. Jones | Chief Technology Advocate | m...@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/groups/opt_out.

    --
    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/groups/opt_out.
  • Thomas Bushnell, BSG at Feb 13, 2013 at 8:02 pm
    If you don't think ++ mutates, what would you think it did?

    On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen wrote:

    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.

    On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
    wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly
    about it.

    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

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

    --
    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/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 13, 2013 at 8:25 pm
    n++ and n-- could just as well have been analogous to succ(n) and pred(n),
    i.e.

    n := 3
    on := n++
    # n is 3
    # on is 4

    With n += 1, this is much clearer (and yes, n = n + 1 would be more
    straightforward still.)


    On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG
    wrote:
    If you don't think ++ mutates, what would you think it did?


    On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who doesn't
    know a C-like language.

    On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
    wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly
    about it.

    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

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

    --
    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/groups/opt_out.
  • Thomas Bushnell, BSG at Feb 13, 2013 at 8:29 pm
    Yes, but that isn't syntactically correct Go code.

    Since "n++" is a statement, not an expression, I'm not sure what real
    confusion happens.

    On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen wrote:

    n++ and n-- could just as well have been analogous to succ(n) and pred(n),
    i.e.

    n := 3
    on := n++
    # n is 3
    # on is 4

    With n += 1, this is much clearer (and yes, n = n + 1 would be more
    straightforward still.)


    On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
    tbushnell@google.com> wrote:
    If you don't think ++ mutates, what would you think it did?


    On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who
    doesn't know a C-like language.

    On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
    wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly
    about it.

    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

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

    --
    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/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 13, 2013 at 8:42 pm
    Alright, I'm going to give up now, but I leave you with this:

    n is a value, not a reference. Why does "n++" mutate n if it doesn't
    re-assign, especially when you need to do s = append(s, x) to grow a slice,
    and a[i] = x rather than v = x to change a value in an array?

    n += 1 / n = n + 1 are both clearer than n++. n++ makes sense because you
    know what it does from C, not because anything else in Go has conditioned
    you to find it intuitive. With less and less people actually starting out
    learning C, and more and more educational institutions using Go as an
    introductory language, you can't really say "++ is obvious, duh."


    On Wed, Feb 13, 2013 at 9:29 PM, Thomas Bushnell, BSG
    wrote:
    Yes, but that isn't syntactically correct Go code.

    Since "n++" is a statement, not an expression, I'm not sure what real
    confusion happens.


    On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    n++ and n-- could just as well have been analogous to succ(n) and
    pred(n), i.e.

    n := 3
    on := n++
    # n is 3
    # on is 4

    With n += 1, this is much clearer (and yes, n = n + 1 would be more
    straightforward still.)


    On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
    tbushnell@google.com> wrote:
    If you don't think ++ mutates, what would you think it did?


    On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who
    doesn't know a C-like language.

    On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
    wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly
    about it.

    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

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

    --
    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/groups/opt_out.
  • Thomas Bushnell, BSG at Feb 13, 2013 at 8:44 pm
    I agree completely that someone without C-like experience might be
    surprised that "i++" is mutating. However, what I'm saying is that there
    isn't any *other *plausible interpretation it could have either. So someone
    without C-like experience would go "hrm, I wonder what that does", which
    isn't so bad. They would not go "ah, this does X" when it actually does
    something else.

    I'm not saying it's obvious or intuitive. I'm saying that someone without C
    experience would not be able to form any conclusion about it.

    This is true precisely because it can only occur as a statement. If it
    could be used as an expression, then certainly it could cause confusion.

    On Wed, Feb 13, 2013 at 12:42 PM, Patrick Mylund Nielsen wrote:

    Alright, I'm going to give up now, but I leave you with this:

    n is a value, not a reference. Why does "n++" mutate n if it doesn't
    re-assign, especially when you need to do s = append(s, x) to grow a slice,
    and a[i] = x rather than v = x to change a value in an array?

    n += 1 / n = n + 1 are both clearer than n++. n++ makes sense because you
    know what it does from C, not because anything else in Go has conditioned
    you to find it intuitive. With less and less people actually starting out
    learning C, and more and more educational institutions using Go as an
    introductory language, you can't really say "++ is obvious, duh."


    On Wed, Feb 13, 2013 at 9:29 PM, Thomas Bushnell, BSG <
    tbushnell@google.com> wrote:
    Yes, but that isn't syntactically correct Go code.

    Since "n++" is a statement, not an expression, I'm not sure what real
    confusion happens.


    On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    n++ and n-- could just as well have been analogous to succ(n) and
    pred(n), i.e.

    n := 3
    on := n++
    # n is 3
    # on is 4

    With n += 1, this is much clearer (and yes, n = n + 1 would be more
    straightforward still.)


    On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
    tbushnell@google.com> wrote:
    If you don't think ++ mutates, what would you think it did?


    On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who
    doesn't know a C-like language.

    On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
    wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly
    about it.

    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

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

    --
    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/groups/opt_out.
  • Patrick Mylund Nielsen at Feb 13, 2013 at 8:48 pm
    Yeah, granted. I'm glad that you can't abuse it in Go.


    On Wed, Feb 13, 2013 at 9:44 PM, Thomas Bushnell, BSG
    wrote:
    I agree completely that someone without C-like experience might be
    surprised that "i++" is mutating. However, what I'm saying is that there
    isn't any *other *plausible interpretation it could have either. So
    someone without C-like experience would go "hrm, I wonder what that does",
    which isn't so bad. They would not go "ah, this does X" when it actually
    does something else.

    I'm not saying it's obvious or intuitive. I'm saying that someone without
    C experience would not be able to form any conclusion about it.

    This is true precisely because it can only occur as a statement. If it
    could be used as an expression, then certainly it could cause confusion.


    On Wed, Feb 13, 2013 at 12:42 PM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    Alright, I'm going to give up now, but I leave you with this:

    n is a value, not a reference. Why does "n++" mutate n if it doesn't
    re-assign, especially when you need to do s = append(s, x) to grow a slice,
    and a[i] = x rather than v = x to change a value in an array?

    n += 1 / n = n + 1 are both clearer than n++. n++ makes sense because you
    know what it does from C, not because anything else in Go has conditioned
    you to find it intuitive. With less and less people actually starting out
    learning C, and more and more educational institutions using Go as an
    introductory language, you can't really say "++ is obvious, duh."


    On Wed, Feb 13, 2013 at 9:29 PM, Thomas Bushnell, BSG <
    tbushnell@google.com> wrote:
    Yes, but that isn't syntactically correct Go code.

    Since "n++" is a statement, not an expression, I'm not sure what real
    confusion happens.


    On Wed, Feb 13, 2013 at 12:25 PM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    n++ and n-- could just as well have been analogous to succ(n) and
    pred(n), i.e.

    n := 3
    on := n++
    # n is 3
    # on is 4

    With n += 1, this is much clearer (and yes, n = n + 1 would be more
    straightforward still.)


    On Wed, Feb 13, 2013 at 9:02 PM, Thomas Bushnell, BSG <
    tbushnell@google.com> wrote:
    If you don't think ++ mutates, what would you think it did?


    On Wed, Feb 13, 2013 at 5:06 AM, Patrick Mylund Nielsen <
    patrick@patrickmylund.com> wrote:
    I disagree. That "++" mutates wouldn't be intuitive to anyone who
    doesn't know a C-like language.

    On Wed, Feb 13, 2013 at 2:04 PM, Jan Mercl wrote:

    On Wed, Feb 13, 2013 at 2:01 PM, Patrick Mylund Nielsen
    wrote:
    I guess b/c `a++` is half the characters of `a += 1`
    Yes, but Go's philosophy is that it terseness isn't a goal--being clear is.
    I don't see why this exists either, but I don't feel very strongly
    about it.

    Well, I think `i++` or `x--` _clearly_ communicates its semantics.

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

    --
    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/groups/opt_out.
  • Starfish at Feb 13, 2013 at 3:12 pm

    Does this not introduce unnecessary choices and make it difficult to
    simplify statements such as:

    a++
    b++
    Here you lost me. What simplification of `a++`, beyond the single CPU
    instruction produced by many compilers, is to be expected?

    -j
    Yes, you're right. I was thinking it could be written 'a, b += 1, 1', but
    it can't of course.

    --
    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/groups/opt_out.
  • David Symonds at Feb 13, 2013 at 12:59 pm
    ken likes ++.

    --
    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/groups/opt_out.
  • Robotic Artichoke at Feb 13, 2013 at 1:26 pm
    With it only being allowed as statements I don't see a real problem. I'll
    continue to use += 1 because I think it's more clear overall and easier to
    change to a different value if needed.

    a++ as an expression and especially ++a as an expression tends to be
    confusing at times and I'm glad they removed that. Sometimes you would have
    to run something just to make sure what you think would happen actually
    happens.

    --
    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/groups/opt_out.
  • Johann Höchtl at Feb 13, 2013 at 4:42 pm

    Am Mittwoch, 13. Februar 2013 14:26:35 UTC+1 schrieb Robotic Artichoke:
    With it only being allowed as statements I don't see a real problem. I'll
    continue to use += 1 because I think it's more clear overall and easier to
    change to a different value if needed.
    But it comes with some surprises: a *= 2 + 2 means a = a * (2 + 2)

    a++ as an expression and especially ++a as an expression tends to be
    confusing at times and I'm glad they removed that. Sometimes you would have
    to run something just to make sure what you think would happen actually
    happens.
    --
    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/groups/opt_out.
  • Minux at Feb 13, 2013 at 5:10 pm

    On Thu, Feb 14, 2013 at 12:42 AM, Johann Höchtl wrote:
    Am Mittwoch, 13. Februar 2013 14:26:35 UTC+1 schrieb Robotic Artichoke:
    With it only being allowed as statements I don't see a real problem. I'll
    continue to use += 1 because I think it's more clear overall and easier to
    change to a different value if needed.
    But it comes with some surprises: a *= 2 + 2 means a = a * (2 + 2)
    the rhs is treated as a group here (*= here is part of the assignment
    statement,
    see http://golang.org/ref/spec#Assignments)
    besides, i think making it expand to a = a * 2 + 2 will confuse a lot more.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 13, '13 at 12:25p
activeFeb 14, '13 at 10:37p
posts30
users15
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase