Not to mention that the change for "for;;" is so counter-intuitive and
violates the try-to-be-explicit principle in Go.
On Wednesday, April 12, 2023 at 9:08:24 AM UTC+8 tapi...@gmail.com wrote:
> The plan for “for;;” is much more risky than “for-each”, because “for;;”
> has more variation uses in reality.
> I have no doubt that many non-bug compatibility-broken or
> performance-degradation cases will be found in the GOEXPERIMENT phase.
>
> On Saturday, March 25, 2023 at 2:44:59 PM UTC+8 Amnon 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/faa17ec8-ba56-4e19-b50d-ec2cc829a5bfn%40googlegroups.com.
