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