On 14 September 2018 at 17:45, Scott Pakin <scott...@pakin.org> wrote:
> 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, 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.
I see that it's possible to make rules that might work. But it's
fairly clear to me that this returnfrom statement is not an
*orthogonal* feature in the way that Go strives to make features
orthogonal to one another. It uses function values, but you can't use
those values in the way that all other function values can be used in
Go. You have to use them in a very stylised way for it to be useful,
with a bunch of fairly arbitrary rules, which to me says that this
doesn't fit well with the language, I'm afraid. I much prefer the
original draft proposal.
cheers,
rog.
>
> — 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.
--
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.
