I would add that Go strives to be a language that is easy to understand.
Any instance where you have to
a) read the spec or be intimately familiar with the language and
b) reason out the behavior instead of understanding it at a glance
is a case where that goal has failed. Of course, there will always be such
cases (hence the occasional "Go quiz" on Twitter). But this particular case
is incredibly common in actual practice. This is not about exotic code,
it's about code any Go programmer writes almost every day.
So, "25% of gophers who didn't read the language spec" already is a flawed
premise. You shouldn't *have* to read the language spec to understand what
Go code does.
On Tue, Apr 11, 2023 at 1:42 AM David Finkel <david.fin...@gmail.com> wrote:
>
>
> On Mon, Apr 10, 2023 at 7:23 PM xi ool <xiioo...@gmail.com> wrote:
>
>> Little late but I have to say the rational seems foolish :
>>
>>
>> 1. Currently 25% of gophers who didn't read the language spec
>> experienced a 'bug' and got unexpected behavior..
>>
>> This premise is a bit suspect.
> The current loop-variable behavior bites almost all gophers both those who
> have and haven't read the spec.
>
>>
>> 1. Solution is to change the language spec and behavior (despite
>> breaking go back compat promise)
>> 2. ...
>> 3. Cut to the future : 25% of gophers who didn;t read the language
>> spec experienced a 'bug' and got unexpected behaviour..
>>
>> Expect to have to explain why all and all2 are different in this example
>> :
>>
>> for _, i := range []int{1, 2, 3, 4} {
>> all = append(all, &i)
>> }
>>
>> var j int
>> for _, j = range []int{1, 2, 3, 4} {
>> all2 = append(all2, &j)
>> }
>>
>> Given that j is outside the loop, and i is declared as part of the loop.
> My intuition before I re-read the language spec (after the first time the
> current semantics bit me) was that the loop variable should be scoped to
> the loop if at all possible.
> The fact that all2 ends up with 4 identical pointers looks to be exactly
> intended in this case.
>
> Note that it's not always so obvious where you're taking a reference to a
> variable, since most methods have pointer-receivers, any method-call that
> stores a pointer to a field on its receiver can do rather surprising things.
>
>
>> also this :
>>
>> - He dreams that he is a powerful sorcerer high on top of a pinnacle
>> commanding the stars, planets, and water. Before long, Mickey wakes up to
>> find that the room is filled with water, and despite the cauldron
>> overflowing, the broom is not stopping. Mickey tries to stop the broom
>> without success; it walks right over him, bringing more and more water.
>> Mickey even tries grabbing one of the buckets, but that too fails.
>> Finally,
>> when the water keeps rising, Mickey, in desperation, grabs a huge ax and
>> chops the broom into pieces. Just when it is all over as Mickey is away,
>> the little wooden split pieces, lying quietly on the floor, begin to come
>> alive, stand upright, grow arms out of their sides, and turn into more
>> brooms with buckets of water. They keep going to the vat and filling it
>> up.
>> Mickey tries to get the water out, but finds that there are too many
>> brooms. Mickey goes to a book and looks for a spell to stop the brooms.
>> Mickey finds himself in a whirlpool. Just then, Yen Sid comes in and sees
>> this, and with a wave of his hands, the water descends and the army of
>> brooms is decreased to one broom.
>> <https://disney.fandom.com/wiki/The_Sorcerer's_Apprentice>
>>
>>
>> On Wednesday, April 5, 2023 at 5:08:07 PM UTC+1 drc...@google.com wrote:
>>
>>> Based on studying large bodies of existing code, you should be about 25x
>>> more scared right now that there's an undetected bug in your code from the
>>> existing semantics -- especially if you haven't written many tests. If
>>> this change does cause a failure in existing code, we have a tool to help
>>> isolate it down to the line, still working on the end-user/programmer
>>> packaging for that tool but it is based on one we used internally for
>>> compiler debugging.
>>>
>>> On Tuesday, April 4, 2023 at 2:57:58 AM UTC-4 Marcello H wrote:
>>>
>>>> The "scary" thing is, that if people don't have enough tests, they are
>>>> probably not aware of such a bug, or can they still be aware somehow?
>>>>
>>>> Op maandag 3 april 2023 om 20:19:33 UTC+2 schreef drc...@google.com:
>>>>
>>>>> And if there is a problem, let us know. Probably around the time 1.21
>>>>> is released we should write up "how to debug this problem if you see it"
>>>>> but we've been working on the tools to automate the search if/when such a
>>>>> bug appears.
>>>>>
>>>>> On Saturday, March 25, 2023 at 10:12:43 AM UTC-4 Eli Bendersky wrote:
>>>>>
>>>>>> On Sat, Mar 25, 2023 at 2:33 AM Amnon <amn...@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks for a very succinct response.
>>>>>>>
>>>>>>> So if I understand the CL, there will be no change in behaviour in
>>>>>>> 1.21, unless you set GOEXPERIMENT=loopvar
>>>>>>>
>>>>>>> - Amnon
>>>>>>>
>>>>>>
>>>>>> That's correct. You (and everyone else) can play with this
>>>>>> GOEXPERIMENT in 1.21 (or now, if using gotip). The most useful thing to
>>>>>> do
>>>>>> would be to run your tests with this experiment set and see what breaks.
>>>>>>
>>>>>> Looking towards the future, this is also related to the forward
>>>>>> compatibility proposal: https://github.com/golang/go/issues/57001
>>>>>>
>>>>>> Eli
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Saturday, 25 March 2023 at 06:56:23 UTC Sean Liao wrote:
>>>>>>>
>>>>>>>> https://go.dev/issue/57969
>>>>>>>>
>>>>>>>> - sean
>>>>>>>>
>>>>>>>> On Sat, Mar 25, 2023, 06:45 Amnon <amn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi Gophers,
>>>>>>>>> Last year there was a discussion about removing one of the
>>>>>>>>> more common gotchas in Go.
>>>>>>>>>
>>>>>>>>> To quote from the discussion:
>>>>>>>>>
>>>>>>>>> the problem is that loops like this one don’t do what they look
>>>>>>>>> like they do:
>>>>>>>>>
>>>>>>>>> var all []*Item
>>>>>>>>> for _, item := range items { all = append(all, &item) }
>>>>>>>>>
>>>>>>>>> That is, this code has a bug. After this loop executes, all
>>>>>>>>> contains len(items) identical pointers, each pointing at the
>>>>>>>>> same Item, holding the last value iterated over. This happens
>>>>>>>>> because the item variable is per-loop, not per-iteration: &item is
>>>>>>>>> the same on every iteration, and item is overwritten on each
>>>>>>>>> iteration.
>>>>>>>>> https://github.com/golang/go/discussions/56010
>>>>>>>>>
>>>>>>>>> What was the resolution of this discussion?
>>>>>>>>> Was the proposed change accepted?
>>>>>>>>> Will it be released in Go 1.21 or 1.22?
>>>>>>>>>
>>>>>>>>> It is hard to figure this out from the discussion. There are
>>>>>>>>> hundreds of comments,
>>>>>>>>> but there is no clear marking of the resolution (apart from the
>>>>>>>>> discussion now being closed) either at the top of bottom of the
>>>>>>>>> discussion.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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.
>>>>>>>>> To view this discussion on the web visit
>>>>>>>>> https://groups.google.com/d/msgid/golang-nuts/5d88208e-fbbf-44d5-b693-50deff176fedn%40googlegroups.com
>>>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/5d88208e-fbbf-44d5-b693-50deff176fedn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>> --
>>>>>>> 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.
>>>>>>>
>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/golang-nuts/aba5e0bd-c676-45f0-a7b7-ce6e23985124n%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/golang-nuts/aba5e0bd-c676-45f0-a7b7-ce6e23985124n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/d5cc7e82-2928-48b1-b4ca-8b7089b2c8aen%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/d5cc7e82-2928-48b1-b4ca-8b7089b2c8aen%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CANrC0BiizSBnq5EiadZ5t026-YSWAK8AuFVt%3DCVYp9f2oE9Mng%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CANrC0BiizSBnq5EiadZ5t026-YSWAK8AuFVt%3DCVYp9f2oE9Mng%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEP_8sY8vwKfOtxLRVCwQtpbZsLSRnD9%3DUQNSv-1AoH6w%40mail.gmail.com.
