Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

[Victor Giordano]

>  In Go, so far changes were for the better and I'm glad to change my
learning if it benefits the mass of my fellow developers.

Maybe. Let's see how times handle it.

TD;DR;
I praise for changes but it is not easy..  I mean, look at our society (the
final reflection of us as an unique aggregated being)... there is room for
improvement. We want a better place, we want changes... but ¿do I wanna
change? This is a very complex affair to discuss with mate 柳  and
facturas 縷.

Dog and cats  allowed too of course




El dom, 1 oct 2023 a las 4:10, TheDiveO ()
escribió:

> actually, language changes happen all the time. In German, there is quite
> some "misuse" esp. by journos that change or follow change in German, not
> necessarily improving clearness. In Go, so far changes were for the better
> and I'm glad to change my learning if it benefits the mass of my fellow
> developers.
> On Saturday, September 30, 2023 at 11:59:36 PM UTC+2 Victor Giordano wrote:
>
>> *Alex*, your second reply was even more powerful in terms of feelings
>> and ideas to work with in order to embrace the change. Probably I'm
>> struggling with an unexpected change... and let's see with time how it goes.
>>
>> *DiveO*, thanks you very mucho for your insight... I see your point. For
>> me... the matter would be like ¿ what happens if a given language you know
>> well suddenly changes the rules for implicit or tacit subject? Where the
>> subject would be the variable and the rules for implicit or tacit subject
>> would be the scope. People may wonder. Again... I guess time will answer us
>> all.
>>
>> Greetings
>>
>> El sábado, 30 de septiembre de 2023 a las 16:55:24 UTC-3, TheDiveO
>> escribió:
>>
>>> Switching between human languages, such as for me, German and English,
>>> required me to learn English at a level that I think in it. Even with their
>>> shared ancestry, I don't expect these languages to use the same structure
>>> and concepts, like loop variable scoping. Admittedly, Go doesn't allow me
>>> to switch in and out into a different language mid sentence, which in human
>>> languages sometimes causes quite some hilarious reactions with my
>>> colleagues.
>>>
>>> On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano
>>> wrote:
>>>
 Thanks Alex, your insight was very helpful.

 Allow me to share the feeling I have => I still struggle a little in my
 mind... I craft web fronts in javascript, and back in golang (and scala or
 java). With this change I will have two different scoping rules... and I
 feel I don't need it (because I learn how to use it well) nor ask for
 them... but it is okay.. changes work that way. The bottom line is: I was
 already comfortable with the language scope rules.

 El sáb, 30 sept 2023 a las 12:37, Axel Wagner (<
 axel.wa...@googlemail.com>) escribió:

> This has come up during the discussion already. I don't know enough
> about other languages to speak with confidence, but apparently there
> already is precedent for this and/or some languages are at least
> considering making a similar change.
>
> Note that scoping rules already vary between languages - in some
> cases, pretty widely. For example, Python is not block scoped - this 
> works:
> def f():
> if True:
> x = 42
> print(x)
> And Perl has dynamic scoping, where variables can be scoped to a call
> stack, instead of any lexical element of the source code. Javascript, as
> far as I know, is pretty notorious for having extremely idiosyncratic
> scoping rules (e.g. it is a common confusion how `this` is scoped in
> different contexts) and also has several different kinds of declarations
> with AFAIK slightly different scoping rules.
> In C, a symbol is only scoped to a single file (as far as the
> processor is concerned) and in there, only from its declaration onwards,
> while in Go, a package-scoped definition can appear in any file of any
> package. And speaking of C, it doesn't have closures at all, so the 
> scoping
> rules of loop variables are *already* very different.
>
> So I think the case that you *currently* don't have to be aware of how
> a language is using scoping is pretty vastly overstated. What's more, the
> majority of programs won't actually be affected by this - and for those
> that are, it seems that empirically, the new rules will align more closely
> with what people expect subconsciously.
>
> I don't think you should worry too much. Run your tests with the new
> loop variable semantics in Go 1.21 to see if everything still works. Most
> likely, it will - or you will discover a bug in your current code.
>
> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano 
> wrote:
>
>> Hi gophers! How you doing?
>>
>> In my work we recently discuss with a buddy about this article
>> 

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

[TheDiveO]

actually, language changes happen all the time. In German, there is quite 
some "misuse" esp. by journos that change or follow change in German, not 
necessarily improving clearness. In Go, so far changes were for the better 
and I'm glad to change my learning if it benefits the mass of my fellow 
developers.   
On Saturday, September 30, 2023 at 11:59:36 PM UTC+2 Victor Giordano wrote:

> *Alex*, your second reply was even more powerful in terms of feelings and 
> ideas to work with in order to embrace the change. Probably I'm 
> struggling with an unexpected change... and let's see with time how it goes.
>
> *DiveO*, thanks you very mucho for your insight... I see your point. For 
> me... the matter would be like ¿ what happens if a given language you know 
> well suddenly changes the rules for implicit or tacit subject? Where the 
> subject would be the variable and the rules for implicit or tacit subject 
> would be the scope. People may wonder. Again... I guess time will answer us 
> all.
>
> Greetings
>
> El sábado, 30 de septiembre de 2023 a las 16:55:24 UTC-3, TheDiveO 
> escribió:
>
>> Switching between human languages, such as for me, German and English, 
>> required me to learn English at a level that I think in it. Even with their 
>> shared ancestry, I don't expect these languages to use the same structure 
>> and concepts, like loop variable scoping. Admittedly, Go doesn't allow me 
>> to switch in and out into a different language mid sentence, which in human 
>> languages sometimes causes quite some hilarious reactions with my 
>> colleagues. 
>>
>> On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano wrote:
>>
>>> Thanks Alex, your insight was very helpful.
>>>
>>> Allow me to share the feeling I have => I still struggle a little in my 
>>> mind... I craft web fronts in javascript, and back in golang (and scala or 
>>> java). With this change I will have two different scoping rules... and I 
>>> feel I don't need it (because I learn how to use it well) nor ask for 
>>> them... but it is okay.. changes work that way. The bottom line is: I was 
>>> already comfortable with the language scope rules.
>>>
>>> El sáb, 30 sept 2023 a las 12:37, Axel Wagner (<
>>> axel.wa...@googlemail.com>) escribió:
>>>
 This has come up during the discussion already. I don't know enough 
 about other languages to speak with confidence, but apparently there 
 already is precedent for this and/or some languages are at least 
 considering making a similar change.

 Note that scoping rules already vary between languages - in some cases, 
 pretty widely. For example, Python is not block scoped - this works:
 def f():
 if True:
 x = 42
 print(x)
 And Perl has dynamic scoping, where variables can be scoped to a call 
 stack, instead of any lexical element of the source code. Javascript, as 
 far as I know, is pretty notorious for having extremely idiosyncratic 
 scoping rules (e.g. it is a common confusion how `this` is scoped in 
 different contexts) and also has several different kinds of declarations 
 with AFAIK slightly different scoping rules.
 In C, a symbol is only scoped to a single file (as far as the processor 
 is concerned) and in there, only from its declaration onwards, while in 
 Go, 
 a package-scoped definition can appear in any file of any package. And 
 speaking of C, it doesn't have closures at all, so the scoping rules of 
 loop variables are *already* very different.

 So I think the case that you *currently* don't have to be aware of how 
 a language is using scoping is pretty vastly overstated. What's more, the 
 majority of programs won't actually be affected by this - and for those 
 that are, it seems that empirically, the new rules will align more closely 
 with what people expect subconsciously.

 I don't think you should worry too much. Run your tests with the new 
 loop variable semantics in Go 1.21 to see if everything still works. Most 
 likely, it will - or you will discover a bug in your current code.

 On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano  
 wrote:

> Hi gophers! How you doing?
>
> In my work we recently discuss with a buddy about this article 
> . I need to talk about this
>
> I appreaciate that golang makes a lot of effort on this. Working with 
> clousures cames with perils and the go vet tool emiting a warning is a 
> great thing.
>
> Althought I do not think that chaning language semantics is something 
> 100% good,  see my point: As long I use several languages for making a 
> system this "scope rule" will mismatch with other languajes, for example, 
> javascript.
>
> So from now onwards I shall be aware that for loops have variables 
> scopes in one fashion in Golang and in other 

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

[Victor Giordano]

*Alex*, your second reply was even more powerful in terms of feelings and 
ideas to work with in order to embrace the change. Probably I'm 
struggling with an unexpected change... and let's see with time how it goes.

*DiveO*, thanks you very mucho for your insight... I see your point. For 
me... the matter would be like ¿ what happens if a given language you know 
well suddenly changes the rules for implicit or tacit subject? Where the 
subject would be the variable and the rules for implicit or tacit subject 
would be the scope. People may wonder. Again... I guess time will answer us 
all.

Greetings

El sábado, 30 de septiembre de 2023 a las 16:55:24 UTC-3, TheDiveO escribió:

> Switching between human languages, such as for me, German and English, 
> required me to learn English at a level that I think in it. Even with their 
> shared ancestry, I don't expect these languages to use the same structure 
> and concepts, like loop variable scoping. Admittedly, Go doesn't allow me 
> to switch in and out into a different language mid sentence, which in human 
> languages sometimes causes quite some hilarious reactions with my 
> colleagues. 
>
> On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano wrote:
>
>> Thanks Alex, your insight was very helpful.
>>
>> Allow me to share the feeling I have => I still struggle a little in my 
>> mind... I craft web fronts in javascript, and back in golang (and scala or 
>> java). With this change I will have two different scoping rules... and I 
>> feel I don't need it (because I learn how to use it well) nor ask for 
>> them... but it is okay.. changes work that way. The bottom line is: I was 
>> already comfortable with the language scope rules.
>>
>> El sáb, 30 sept 2023 a las 12:37, Axel Wagner () 
>> escribió:
>>
>>> This has come up during the discussion already. I don't know enough 
>>> about other languages to speak with confidence, but apparently there 
>>> already is precedent for this and/or some languages are at least 
>>> considering making a similar change.
>>>
>>> Note that scoping rules already vary between languages - in some cases, 
>>> pretty widely. For example, Python is not block scoped - this works:
>>> def f():
>>> if True:
>>> x = 42
>>> print(x)
>>> And Perl has dynamic scoping, where variables can be scoped to a call 
>>> stack, instead of any lexical element of the source code. Javascript, as 
>>> far as I know, is pretty notorious for having extremely idiosyncratic 
>>> scoping rules (e.g. it is a common confusion how `this` is scoped in 
>>> different contexts) and also has several different kinds of declarations 
>>> with AFAIK slightly different scoping rules.
>>> In C, a symbol is only scoped to a single file (as far as the processor 
>>> is concerned) and in there, only from its declaration onwards, while in Go, 
>>> a package-scoped definition can appear in any file of any package. And 
>>> speaking of C, it doesn't have closures at all, so the scoping rules of 
>>> loop variables are *already* very different.
>>>
>>> So I think the case that you *currently* don't have to be aware of how a 
>>> language is using scoping is pretty vastly overstated. What's more, the 
>>> majority of programs won't actually be affected by this - and for those 
>>> that are, it seems that empirically, the new rules will align more closely 
>>> with what people expect subconsciously.
>>>
>>> I don't think you should worry too much. Run your tests with the new 
>>> loop variable semantics in Go 1.21 to see if everything still works. Most 
>>> likely, it will - or you will discover a bug in your current code.
>>>
>>> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano  
>>> wrote:
>>>
 Hi gophers! How you doing?

 In my work we recently discuss with a buddy about this article 
 . I need to talk about this

 I appreaciate that golang makes a lot of effort on this. Working with 
 clousures cames with perils and the go vet tool emiting a warning is a 
 great thing.

 Althought I do not think that chaning language semantics is something 
 100% good,  see my point: As long I use several languages for making a 
 system this "scope rule" will mismatch with other languajes, for example, 
 javascript.

 So from now onwards I shall be aware that for loops have variables 
 scopes in one fashion in Golang and in other fashion in another 
 languages... so at the end of the day, I feel like is adding some burden. 
 If for development we can use a single and sole language (Sauron don't 
 read 
 this :P !) I would think this change is good, but that is not the case in 
 now-a-days. I try to think that with time, perhaps other languages evolves 
 it this way... but.. ¿what if I wanna have my "for loop" with legacy scope 
 (block scope, not per iteration scope)? 

 So... I expect to the readers to talk with 

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

[TheDiveO]

Switching between human languages, such as for me, German and English, 
required me to learn English at a level that I think in it. Even with their 
shared ancestry, I don't expect these languages to use the same structure 
and concepts, like loop variable scoping. Admittedly, Go doesn't allow me 
to switch in and out into a different language mid sentence, which in human 
languages sometimes causes quite some hilarious reactions with my 
colleagues. 

On Saturday, September 30, 2023 at 6:35:54 PM UTC+2 Victor Giordano wrote:

> Thanks Alex, your insight was very helpful.
>
> Allow me to share the feeling I have => I still struggle a little in my 
> mind... I craft web fronts in javascript, and back in golang (and scala or 
> java). With this change I will have two different scoping rules... and I 
> feel I don't need it (because I learn how to use it well) nor ask for 
> them... but it is okay.. changes work that way. The bottom line is: I was 
> already comfortable with the language scope rules.
>
> El sáb, 30 sept 2023 a las 12:37, Axel Wagner () 
> escribió:
>
>> This has come up during the discussion already. I don't know enough about 
>> other languages to speak with confidence, but apparently there already is 
>> precedent for this and/or some languages are at least considering making a 
>> similar change.
>>
>> Note that scoping rules already vary between languages - in some cases, 
>> pretty widely. For example, Python is not block scoped - this works:
>> def f():
>> if True:
>> x = 42
>> print(x)
>> And Perl has dynamic scoping, where variables can be scoped to a call 
>> stack, instead of any lexical element of the source code. Javascript, as 
>> far as I know, is pretty notorious for having extremely idiosyncratic 
>> scoping rules (e.g. it is a common confusion how `this` is scoped in 
>> different contexts) and also has several different kinds of declarations 
>> with AFAIK slightly different scoping rules.
>> In C, a symbol is only scoped to a single file (as far as the processor 
>> is concerned) and in there, only from its declaration onwards, while in Go, 
>> a package-scoped definition can appear in any file of any package. And 
>> speaking of C, it doesn't have closures at all, so the scoping rules of 
>> loop variables are *already* very different.
>>
>> So I think the case that you *currently* don't have to be aware of how a 
>> language is using scoping is pretty vastly overstated. What's more, the 
>> majority of programs won't actually be affected by this - and for those 
>> that are, it seems that empirically, the new rules will align more closely 
>> with what people expect subconsciously.
>>
>> I don't think you should worry too much. Run your tests with the new loop 
>> variable semantics in Go 1.21 to see if everything still works. Most 
>> likely, it will - or you will discover a bug in your current code.
>>
>> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano  
>> wrote:
>>
>>> Hi gophers! How you doing?
>>>
>>> In my work we recently discuss with a buddy about this article 
>>> . I need to talk about this
>>>
>>> I appreaciate that golang makes a lot of effort on this. Working with 
>>> clousures cames with perils and the go vet tool emiting a warning is a 
>>> great thing.
>>>
>>> Althought I do not think that chaning language semantics is something 
>>> 100% good,  see my point: As long I use several languages for making a 
>>> system this "scope rule" will mismatch with other languajes, for example, 
>>> javascript.
>>>
>>> So from now onwards I shall be aware that for loops have variables 
>>> scopes in one fashion in Golang and in other fashion in another 
>>> languages... so at the end of the day, I feel like is adding some burden. 
>>> If for development we can use a single and sole language (Sauron don't read 
>>> this :P !) I would think this change is good, but that is not the case in 
>>> now-a-days. I try to think that with time, perhaps other languages evolves 
>>> it this way... but.. ¿what if I wanna have my "for loop" with legacy scope 
>>> (block scope, not per iteration scope)? 
>>>
>>> So... I expect to the readers to talk with me, showing what they see and 
>>> feel. Is not my intention to generate hard feelings at all. I'm a person 
>>> that work crafting system in group with others.. I have had terrible 
>>> nightmares working with Scala where implicits and invoking methods as they 
>>> were feilds were terrible ideas for working in group (perhaps not if you 
>>> work solo). And this feature recalls me those feelings.
>>>
>>> Greetings
>>> Víctor.
>>>
>>> -- 
>>> 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 
>>> 

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

['Axel Wagner' via golang-nuts]

So, how often do you depend on this particular scoping behavior, in Go or
JS? Do you have any example of where you intentionally rely on the current
behavior, that might break with the new one?

I think it's important to emphasize that we do not know of a *single case*
where the current behavior was usefully taken advantage of. Even strong
opponents of the change failed to produce any - they just created synthetic
(and extremely obfuscated) cases that would change behavior, without any
reference to real code these cases where taken from.

You keep asserting that you have to remember different sets of rules - I
just don't think that's true, in any real sense. I think you'll find that
in reality, it will have literally no effect on you - except that it is not
unlikely to fix a bug or two in your existing code base. Because it turns
out that no one actually thinks at that level about scoping.

On Sat, Sep 30, 2023 at 6:35 PM Victor Giordano 
wrote:

> Thanks Alex, your insight was very helpful.
>
> Allow me to share the feeling I have => I still struggle a little in my
> mind... I craft web fronts in javascript, and back in golang (and scala or
> java). With this change I will have two different scoping rules... and I
> feel I don't need it (because I learn how to use it well) nor ask for
> them... but it is okay.. changes work that way. The bottom line is: I was
> already comfortable with the language scope rules.
>
> El sáb, 30 sept 2023 a las 12:37, Axel Wagner (<
> axel.wagner...@googlemail.com>) escribió:
>
>> This has come up during the discussion already. I don't know enough about
>> other languages to speak with confidence, but apparently there already is
>> precedent for this and/or some languages are at least considering making a
>> similar change.
>>
>> Note that scoping rules already vary between languages - in some cases,
>> pretty widely. For example, Python is not block scoped - this works:
>> def f():
>> if True:
>> x = 42
>> print(x)
>> And Perl has dynamic scoping, where variables can be scoped to a call
>> stack, instead of any lexical element of the source code. Javascript, as
>> far as I know, is pretty notorious for having extremely idiosyncratic
>> scoping rules (e.g. it is a common confusion how `this` is scoped in
>> different contexts) and also has several different kinds of declarations
>> with AFAIK slightly different scoping rules.
>> In C, a symbol is only scoped to a single file (as far as the processor
>> is concerned) and in there, only from its declaration onwards, while in Go,
>> a package-scoped definition can appear in any file of any package. And
>> speaking of C, it doesn't have closures at all, so the scoping rules of
>> loop variables are *already* very different.
>>
>> So I think the case that you *currently* don't have to be aware of how a
>> language is using scoping is pretty vastly overstated. What's more, the
>> majority of programs won't actually be affected by this - and for those
>> that are, it seems that empirically, the new rules will align more closely
>> with what people expect subconsciously.
>>
>> I don't think you should worry too much. Run your tests with the new loop
>> variable semantics in Go 1.21 to see if everything still works. Most
>> likely, it will - or you will discover a bug in your current code.
>>
>> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano 
>> wrote:
>>
>>> Hi gophers! How you doing?
>>>
>>> In my work we recently discuss with a buddy about this article
>>> . I need to talk about this
>>>
>>> I appreaciate that golang makes a lot of effort on this. Working with
>>> clousures cames with perils and the go vet tool emiting a warning is a
>>> great thing.
>>>
>>> Althought I do not think that chaning language semantics is something
>>> 100% good,  see my point: As long I use several languages for making a
>>> system this "scope rule" will mismatch with other languajes, for example,
>>> javascript.
>>>
>>> So from now onwards I shall be aware that for loops have variables
>>> scopes in one fashion in Golang and in other fashion in another
>>> languages... so at the end of the day, I feel like is adding some burden.
>>> If for development we can use a single and sole language (Sauron don't read
>>> this :P !) I would think this change is good, but that is not the case in
>>> now-a-days. I try to think that with time, perhaps other languages evolves
>>> it this way... but.. ¿what if I wanna have my "for loop" with legacy scope
>>> (block scope, not per iteration scope)?
>>>
>>> So... I expect to the readers to talk with me, showing what they see and
>>> feel. Is not my intention to generate hard feelings at all. I'm a person
>>> that work crafting system in group with others.. I have had terrible
>>> nightmares working with Scala where implicits and invoking methods as they
>>> were feilds were terrible ideas for working in group (perhaps not if you
>>> work solo). And this 

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

[Victor Giordano]

Thanks Alex, your insight was very helpful.

Allow me to share the feeling I have => I still struggle a little in my
mind... I craft web fronts in javascript, and back in golang (and scala or
java). With this change I will have two different scoping rules... and I
feel I don't need it (because I learn how to use it well) nor ask for
them... but it is okay.. changes work that way. The bottom line is: I was
already comfortable with the language scope rules.

El sáb, 30 sept 2023 a las 12:37, Axel Wagner (<
axel.wagner...@googlemail.com>) escribió:

> This has come up during the discussion already. I don't know enough about
> other languages to speak with confidence, but apparently there already is
> precedent for this and/or some languages are at least considering making a
> similar change.
>
> Note that scoping rules already vary between languages - in some cases,
> pretty widely. For example, Python is not block scoped - this works:
> def f():
> if True:
> x = 42
> print(x)
> And Perl has dynamic scoping, where variables can be scoped to a call
> stack, instead of any lexical element of the source code. Javascript, as
> far as I know, is pretty notorious for having extremely idiosyncratic
> scoping rules (e.g. it is a common confusion how `this` is scoped in
> different contexts) and also has several different kinds of declarations
> with AFAIK slightly different scoping rules.
> In C, a symbol is only scoped to a single file (as far as the processor is
> concerned) and in there, only from its declaration onwards, while in Go, a
> package-scoped definition can appear in any file of any package. And
> speaking of C, it doesn't have closures at all, so the scoping rules of
> loop variables are *already* very different.
>
> So I think the case that you *currently* don't have to be aware of how a
> language is using scoping is pretty vastly overstated. What's more, the
> majority of programs won't actually be affected by this - and for those
> that are, it seems that empirically, the new rules will align more closely
> with what people expect subconsciously.
>
> I don't think you should worry too much. Run your tests with the new loop
> variable semantics in Go 1.21 to see if everything still works. Most
> likely, it will - or you will discover a bug in your current code.
>
> On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano 
> wrote:
>
>> Hi gophers! How you doing?
>>
>> In my work we recently discuss with a buddy about this article
>> . I need to talk about this
>>
>> I appreaciate that golang makes a lot of effort on this. Working with
>> clousures cames with perils and the go vet tool emiting a warning is a
>> great thing.
>>
>> Althought I do not think that chaning language semantics is something
>> 100% good,  see my point: As long I use several languages for making a
>> system this "scope rule" will mismatch with other languajes, for example,
>> javascript.
>>
>> So from now onwards I shall be aware that for loops have variables scopes
>> in one fashion in Golang and in other fashion in another languages... so at
>> the end of the day, I feel like is adding some burden. If for development
>> we can use a single and sole language (Sauron don't read this :P !) I would
>> think this change is good, but that is not the case in now-a-days. I try to
>> think that with time, perhaps other languages evolves it this way... but..
>> ¿what if I wanna have my "for loop" with legacy scope (block scope, not per
>> iteration scope)?
>>
>> So... I expect to the readers to talk with me, showing what they see and
>> feel. Is not my intention to generate hard feelings at all. I'm a person
>> that work crafting system in group with others.. I have had terrible
>> nightmares working with Scala where implicits and invoking methods as they
>> were feilds were terrible ideas for working in group (perhaps not if you
>> work solo). And this feature recalls me those feelings.
>>
>> Greetings
>> Víctor.
>>
>> --
>> 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/5f31be67-d246-4778-a373-69d525772974n%40googlegroups.com
>> 
>> .
>>
>

-- 
V

-- 
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/CAPUu9suE6D71rHms0vaDc77ecW42jbtbY0q8okNVkD%3DC-NgcQw%40mail.gmail.com.

Re: [go-nuts] About variables have per-iteration scope instead of per-loop scope

['Axel Wagner' via golang-nuts]

This has come up during the discussion already. I don't know enough about
other languages to speak with confidence, but apparently there already is
precedent for this and/or some languages are at least considering making a
similar change.

Note that scoping rules already vary between languages - in some cases,
pretty widely. For example, Python is not block scoped - this works:
def f():
if True:
x = 42
print(x)
And Perl has dynamic scoping, where variables can be scoped to a call
stack, instead of any lexical element of the source code. Javascript, as
far as I know, is pretty notorious for having extremely idiosyncratic
scoping rules (e.g. it is a common confusion how `this` is scoped in
different contexts) and also has several different kinds of declarations
with AFAIK slightly different scoping rules.
In C, a symbol is only scoped to a single file (as far as the processor is
concerned) and in there, only from its declaration onwards, while in Go, a
package-scoped definition can appear in any file of any package. And
speaking of C, it doesn't have closures at all, so the scoping rules of
loop variables are *already* very different.

So I think the case that you *currently* don't have to be aware of how a
language is using scoping is pretty vastly overstated. What's more, the
majority of programs won't actually be affected by this - and for those
that are, it seems that empirically, the new rules will align more closely
with what people expect subconsciously.

I don't think you should worry too much. Run your tests with the new loop
variable semantics in Go 1.21 to see if everything still works. Most
likely, it will - or you will discover a bug in your current code.

On Sat, Sep 30, 2023 at 4:58 PM Victor Giordano 
wrote:

> Hi gophers! How you doing?
>
> In my work we recently discuss with a buddy about this article
> . I need to talk about this
>
> I appreaciate that golang makes a lot of effort on this. Working with
> clousures cames with perils and the go vet tool emiting a warning is a
> great thing.
>
> Althought I do not think that chaning language semantics is something 100%
> good,  see my point: As long I use several languages for making a system
> this "scope rule" will mismatch with other languajes, for example,
> javascript.
>
> So from now onwards I shall be aware that for loops have variables scopes
> in one fashion in Golang and in other fashion in another languages... so at
> the end of the day, I feel like is adding some burden. If for development
> we can use a single and sole language (Sauron don't read this :P !) I would
> think this change is good, but that is not the case in now-a-days. I try to
> think that with time, perhaps other languages evolves it this way... but..
> ¿what if I wanna have my "for loop" with legacy scope (block scope, not per
> iteration scope)?
>
> So... I expect to the readers to talk with me, showing what they see and
> feel. Is not my intention to generate hard feelings at all. I'm a person
> that work crafting system in group with others.. I have had terrible
> nightmares working with Scala where implicits and invoking methods as they
> were feilds were terrible ideas for working in group (perhaps not if you
> work solo). And this feature recalls me those feelings.
>
> Greetings
> Víctor.
>
> --
> 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/5f31be67-d246-4778-a373-69d525772974n%40googlegroups.com
> 
> .
>

-- 
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/CAEkBMfFC7hvhi%3Deg8h5ard54hn7Wo-tjEPfbJ82SC6QbZ5PEYw%40mail.gmail.com.

[go-nuts] About variables have per-iteration scope instead of per-loop scope

[Victor Giordano]

Hi gophers! How you doing?

In my work we recently discuss with a buddy about this article 
. I need to talk about this

I appreaciate that golang makes a lot of effort on this. Working with 
clousures cames with perils and the go vet tool emiting a warning is a 
great thing.

Althought I do not think that chaning language semantics is something 100% 
good,  see my point: As long I use several languages for making a system 
this "scope rule" will mismatch with other languajes, for example, 
javascript.

So from now onwards I shall be aware that for loops have variables scopes 
in one fashion in Golang and in other fashion in another languages... so at 
the end of the day, I feel like is adding some burden. If for development 
we can use a single and sole language (Sauron don't read this :P !) I would 
think this change is good, but that is not the case in now-a-days. I try to 
think that with time, perhaps other languages evolves it this way... but.. 
¿what if I wanna have my "for loop" with legacy scope (block scope, not per 
iteration scope)? 

So... I expect to the readers to talk with me, showing what they see and 
feel. Is not my intention to generate hard feelings at all. I'm a person 
that work crafting system in group with others.. I have had terrible 
nightmares working with Scala where implicits and invoking methods as they 
were feilds were terrible ideas for working in group (perhaps not if you 
work solo). And this feature recalls me those feelings.

Greetings
Víctor.

-- 
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/5f31be67-d246-4778-a373-69d525772974n%40googlegroups.com.