If I may quote myself: > And no matter which choice you make for the language - it means that if the programmers wanted the other, they'd have to jump through annoying hoops and get confusing and hard to debug problems.
Having a mechanism to get one or the other semantic doesn't change the fact that it's easy to choose wrongly by accident, as long as the effect is implicit. In fact, the mechanism you propose (AIUI) seems extra confusing: Having a function value sometimes create a new dynamic scope and sometimes not, is weird and seems like a recipe for frustration. But really, convincing me isn't really the point, which is why I'm not super invested in litigating this (otherwise I might try to come up with realistic examples, for instance. Or explain further why I'm still not sure that this can be implemented efficiently). I'm just re-stating what, in the past, where the reasons why things like this have been rejected. In order to predict what I would consider a likely outcome of a proposal like this. If you think I am wrong or misunderstanding you, you can always file a proposal to get a more official response. On Tue, Feb 20, 2024 at 8:18 PM Sam Vilain <s...@vilain.net> wrote: > On 2/17/24 1:32 AM, Axel Wagner wrote: > > On Sat, Feb 17, 2024 at 2:09 AM Sam Vilain <s...@vilain.net> wrote: > >> I would argue that the matter can be simply decided by choosing the >> *calling* stack, not the destination stack. >> > > I agree that this is *one choice*. But the point is, that *sometimes* > you'd want one and *sometimes* the other. And no matter which choice you > make for the language - it means that if the programmers wanted the other, > they'd have to jump through annoying hoops and get confusing and hard to > debug problems. So if you want to justify either choice, you have to make > an argument that it is so overwhelmingly more common what people would > want, that the cost of running into these problems is small enough to be > justified by the benefit. > > I think that's a hard case to make. > > Alex, I agree that there are cases where you might prefer one versus the > other. However, you cut out the part of my reply where I pointed out it > was possible to choose semantics by either returning a closure (context is > the source stack) or a bound method (context is the destination stack). > Both of these values can be used interchangeably, as they have the same > type, func ..., and so the caller does not need to care whether the > function they are calling uses the calling context or the original > context. Were you not convinced by the argument? > > Sam > -- 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/CAEkBMfE-zaJ3ttZhONu2yZ0uOgh6V8gk5Xkng4zr%2B1EEo5k1kA%40mail.gmail.com.
