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 <vitucho3...@gmail.com>
> wrote:
>
>> Hi gophers! How you doing?
>>
>> In my work we recently discuss with a buddy about this article
>> <https://go.dev/blog/loopvar-preview>. 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
>> <https://groups.google.com/d/msgid/golang-nuts/5f31be67-d246-4778-a373-69d525772974n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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.

Reply via email to