I've hit this problems a few times, and I immediately thumbs-upped that issue report.
To correct @Ben, I suggest the purest reasoning for an error being displayed is "The process completed, and did not succeed". In your case, @Ben, yeah, it was killed while waiting on something, but the normal case is when I kick off an A/B test with too many iterations, or that is particularly heavy. It's easy enough to do an A/B test locally, but if you're changing someone's snippet and resharing, or else producing the test to send to a colleague. It happens seldom enough that I go through the same little confusion-frustration-shorten sequence whenever this happens. If the process got killed, whatever it's running on, it's worth notifying the remote (us) that it had to be killed, even if it doesn't include a stack-trace. On Monday, April 11, 2022 at 5:04:21 PM UTC-5 ben...@gmail.com wrote: > Depending on implementation, infinite recursion is not guaranteed to blow >> the stack for the program given. The function call is in tail position, so >> a tail-call optimization (TCO) pass would be able to rewrite the program >> into an infinite loop by reusing the existing stack frame for each >> invocation of f[0]. >> > > Understood. But I think there are two reasons this code in the playground > should still show an error: > > 1) The existing Go compilers don't do tail-call optimization, so keeping > the discussion real and concrete, they will overflow the stack. > 2) Even if they did implement tail-call optimization, this would be an > infinite loop, so it should show a timeout error, like an infinite for loop > does: https://go.dev/play/p/GH67vNtpZyp > > -Ben > > -- 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/330aa6aa-d975-422d-8405-a261b5fd3b1an%40googlegroups.com.
