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 <vituc...@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...@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/bf478159-7f74-4151-acc8-f663f42c557en%40googlegroups.com.
