For Go 1.1 we propose to specify when a function requires a return statement. The 6g and gccgo compilers agree today, by design, but the details have never been part of the spec. At the same time, we propose to make the requirements a little less strict.The details are at http://golang.org/s/go11return. Comments are welcome in this thread.
At the same time, we propose to make the requirements a little less strict.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Yes, I plan to add checking for the new return rules in go/types very soon.
- gri
--
Also many functions name parameters for documentation purposes only, with no intention of using the naked return.Russ
There's probably a case to be made and a discussion that could be had. But having allowed the naked 'return' in Go 1, we are not in a position now to remove it.Russ
Delayed realization ... go vet or fmt could "clothe" naked returns with the formal parameter names, then Rob's concerns would be assuaged and any code--sans such polishing--would still be Go 1 compliant. There can be no doubt about this since the names have been parsed at the top and are there to be appended at the bottom...
The implementation (Go 1.0) already disallows naked return statements with shadowed return variables, unless this is changing in Go 1.1.
I'd like to put forward support for the second alternative, excluding items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted in Issue 65. As Russ notes, it is easy to avoid the requirement for an artificial panic with the current implementation, and I don't believe that the items' exclusion does result in an irregularity.
I'd like to put forward support for the second alternative, excluding items 5 and 8. I believe that 5 and 8 are orthogonal to the problem noted in Issue 65. As Russ notes, it is easy to avoid the requirement for an artificial panic with the current implementation, and I don't believe that the items' exclusion does result in an irregularity.
Dan
function in 18 Go source files (and cca only one per three packages).2,112 such functions in 38,734 Go source files is about 1 such
One Go source file typically consists of more than one function. Let
me estimate there are at least 5 funcs/package on average.
Whatever the resolution is going to be, it can improve the life of
perhaps not even 1% of function written out there. Which I'm not sure
is worth of the effort.
In my opinion the current behaviour is acceptable, further complicatingthe spec is not worth it. At least I don't have to additionallyremember or teach the less strict rules ;-)
On consideration, I believe that most cases where panic("unreachable")
is used could be rewritten to avoid the panic under rules 1 through 4,
and those that cannot must be so complex that the presence of a panic
is a signal to the reader to exercise caution.
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.