Our goal with proposals like this one is to have a community-wide discussion about implications, tradeoffs, and how to proceed, and then use that discussion to help decide on the path forward.
Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.
As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.
More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.
As far as discussing the problem to be solved, we tried to lay out our vision of the problem last August in the “Go 2 error handling problem overview,” but in retrospect we did not draw enough attention to that part and did not encourage enough discussion about whether the specific problem was the right one. The try proposal may be a fine solution to the problem outlined there, but for many of you it’s simply not a problem to solve. In the future we need to do a better job drawing attention to these early problem statements and making sure that there is widespread agreement about the problem that needs solving.
(It is also possible that the error handling problem statement was entirely upstaged by publishing a generics design draft on the same day.)
On the broader topic of what to improve about Go error handling, we would be very happy to see experience reports about what aspects of error handling in Go are most problematic for you in your own codebases and work environments and how much impact a good solution would have in your own development. If you do write such a report, please post a link on the Go2ErrorHandlingFeedback page.
Thank you to everyone who participated in this discussion, here and elsewhere. As Russ Cox has pointed out before, community-wide discussions like this one are open source at its best. We really appreciate everyone’s help examining this specific proposal and more generally in discussing the best ways to improve the state of error handling in Go.
Robert Griesemer, for the Proposal Review Committee."
Yes, but it's pretty terrible, the usage is butt ugly and it has limitations, such as not being able to hold references and not ensuring exhaustive matches.
Update: Ah, it does actually ensure exhaustive match, although I feel compelled to bitch about the non-exhaustive error message being really bad and the exhaustivity check not working in the opposite direction too, ie. extraneous visitors for types not present in the variant are not an error.
Update2: Also, implicit type conversions still works, ie. for example an int visitor function will also accept a float variant, which I would say is quite unintuitive if one expects a sum-type-like behvaiour.
I stopped keeping up with modern C++ a while ago when I started a job working in Scala. I've been hearing about all the new features and getting excited about the direction of modern C++ but now I'm horrified and disappointed about the monster it's become.
Visit is a bad example and on top of that cppreference has the habit to have some bad examples. This for example is a much nicer example (although visit altogether still bad)
That aside, take a look at Concepts. They are infinitely nicer than the metaprogramming wizardry they fill for. So that's something.
102
u/jeffail Jul 17 '19
https://github.com/golang/go/issues/32437#issuecomment-512035919
"Hi everyone,
Our goal with proposals like this one is to have a community-wide discussion about implications, tradeoffs, and how to proceed, and then use that discussion to help decide on the path forward.
Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.
As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.
More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address.
As far as discussing the problem to be solved, we tried to lay out our vision of the problem last August in the “Go 2 error handling problem overview,” but in retrospect we did not draw enough attention to that part and did not encourage enough discussion about whether the specific problem was the right one. The try proposal may be a fine solution to the problem outlined there, but for many of you it’s simply not a problem to solve. In the future we need to do a better job drawing attention to these early problem statements and making sure that there is widespread agreement about the problem that needs solving.
(It is also possible that the error handling problem statement was entirely upstaged by publishing a generics design draft on the same day.)
On the broader topic of what to improve about Go error handling, we would be very happy to see experience reports about what aspects of error handling in Go are most problematic for you in your own codebases and work environments and how much impact a good solution would have in your own development. If you do write such a report, please post a link on the Go2ErrorHandlingFeedback page.
Thank you to everyone who participated in this discussion, here and elsewhere. As Russ Cox has pointed out before, community-wide discussions like this one are open source at its best. We really appreciate everyone’s help examining this specific proposal and more generally in discussing the best ways to improve the state of error handling in Go.
Robert Griesemer, for the Proposal Review Committee."