l <0xj...@gmail.com>
>> Date: Tue, Apr 11, 2023 at 9:11 AM
>> Subject: Re: [go-nuts] Redfining loop variable semantics - what's the
>> plan?
>> To: Axel Wagner
>>
>>
>> On Tue, Apr 11, 2023 at 7:46 AM 'Axel Wagner' via golang-nuts
>
: Tue, Apr 11, 2023 at 9:11 AM
> Subject: Re: [go-nuts] Redfining loop variable semantics - what's the plan?
> To: Axel Wagner
>
>
> On Tue, Apr 11, 2023 at 7:46 AM 'Axel Wagner' via golang-nuts
> wrote:
>
> > You shouldn't *have* to read the language spec
Resending to the mailing list as that was my intention but I errored
again. Did the gmail UI changed again?
-- Forwarded message -
From: Jan Mercl <0xj...@gmail.com>
Date: Tue, Apr 11, 2023 at 9:11 AM
Subject: Re: [go-nuts] Redfining loop variable semantics - what's t
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
On Mon, Apr 10, 2023 at 7:23 PM xi ool 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 be
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..
2. Solution is to change the language spec and behavior (despite
breaking go back compat promise)
3. ...
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
i
On Tuesday, 4 April 2023 at 07:57:58 UTC+1 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?
Do you mean bugs due to the *old* behaviour? You're quite right, the first
they may be aware
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
> release
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 w
On Sat, Mar 25, 2023 at 2:33 AM Amnon 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
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
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
https://go.dev/issue/57969
- sean
On Sat, Mar 25, 2023, 06:45 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
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
14 matches
Mail list logo
