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.
