Forgive me if I missed that, but what if I have multiple context vars, because I need to pass different (derived) contexts into different functions/receivers? Take unit tests as real-world examples.
On Wednesday, February 21, 2024 at 1:37:05 AM UTC+1 Sam Vilain wrote: > Alright, well thanks for your input. > > I do think these questions can be answered; exploring the use cases in a > proposal format should hopefully show that the impact of closures would not > normally be an issue. Possibly the worst case is if you had a library to > some external service, and at some low layer you're using a closure, well > you might need to refactor that if you wanted to add cross–service tracing > support. But to be honest, it's probably better that the state you're > depending on is captured in a struct instead of being scattered about > loosely in a scope as with a closure. And the common practice in Go is to > return types that satisfy interfaces, not function references that you > blind call. > > I think I will submit a proposal, but please don't take that to imply that > I think you're "wrong, or mistaken". Your concerns are legitimate and the > proposal should answer them cleanly. In the proposal format, hopefully the > "litigation", or more exploration of possible uses and abuses of the > system, along with performance concerns, can be addressed. I don't want to > be dismissive of them, I just want to understand them. > > I had a brief look on the Golang issues in Github and could not find any > prior proposals along this line using "context" and "dynamic scope" as > search terms, so I'll submit this as a "new" proposal for now. > > Thanks again, and truly—thanks for responding, >100% better than people > who just rolled eyes and marked thread as read. > > Cheers, > Sam > On 2/20/24 3:35 PM, Axel Wagner wrote: > > 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 >> > -- > 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/98dc6699-2b2e-48a8-bc4c-fc70406940e5n%40googlegroups.com.
