On Friday, September 14, 2018 at 12:30:46 AM UTC-6, rog wrote:
>
> What about here, where the call stack associated with g is still live?
>
> func g() error {
> Top:
> f := func(err error) { returnfrom Top, nil }
> c := make(chan struct{})
> go func() {
> defer close(c)
> f(nil)
> }()
> <-c
> }
>
> ?
>
Yeah, in my proposal, under Issues
<https://gist.github.com/spakin/86ea86ca48aefc78b672636914f4fc23#issues>, I
do mention that the interaction with goroutines needs to be thought through.
With respect to your example, I hope we can all agree that it would be odd
and un-Go-like for the goroutine to cause g to return, right? Hence, I'd
argue that the best solution would be to generate an error at compile
time. "I see that the evaluation of an anonymous function is being passed
to go. That function calls f. f lexically includes a returnfrom. The
returnfrom lexically refers to a label, Top, that's outside the anonymous
function. Error!" I'm not positive the compiler can do that in all cases,
but I'd think a conservative approach ought to work. That is, if an
anonymous function *might* call a function that *might* returnfrom an
invalid location, the compiler should still issue an error message. I
can't imagine such conservativism causing headaches for real code, only for
contrived examples.
If it's really not possible to make compile-time detection work, I'd say
that the returnfrom in f should exit the goroutine but not return its
argument from g. This is consistent with the case of returning from a
continuation that's no longer live.
— Scott
--
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.
For more options, visit https://groups.google.com/d/optout.
