On 3/12/21 7:16 AM, Axel Wagner wrote: > I find named returns produce more readable code but I avoid them when > returning a map. > > > Personally, I would recommend avoiding naked returns in all cases. In the best > case, a naked return is less explicit and requires readers to think about what > is returned. In the worst case, a naked return can introduce subtle shadowing > bugs (this has happened in production code, multiple times). > > I don't think the convenience justifies the cost.
Shadowing is an issue that needs to be dealt with, in any case. Think about = less readable. > > Why doesn't go auto init or make an empty map for a named return to avoid > the potential chance of a panic due to operating on a nil return? > > > It auto-initializes every variable to its zero value. It would be very strange > to make an exception for maps. And named returns aren't really different from > regular variables in this regard. > > I also don't think there are many cases where you'd *want* to implicitly > return > an empty, non-nil map. A nil map says "there is no map", whereas an empty map > says "there is a map, but it has no elements". It seems very appropriate that > if > you want to say the latter, you have to explicitly do so. I would argue that a string could be nil but isn't and that being 0 len is a good thing. Ergo, it is strange for a map to be doing premature optimisation, when you could test it for 0 size. More likely, it is an artifact of make coming to the language later on and perhaps is tied by the go promise, unfortunately? It might have also been a not tiny amount of work for a relatively small benefit. We are encouraged to use make to initialise maps. I also replace err.Error() with a function that returns "". Incidentally, I would be happy with err != "". err.Error() has also lead to bugs in stdlib. So maybe I just have a different point of view? Maybe null safety will come, eventually as it was quite high on the survey and likely increasing as more languages provide this feature and users acknowledge it. Are there any better tools than golang-shadow and golang-nilness, for these problems? -- 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/d89835e2-4db3-e34e-416c-a7db6d472a79%40gmail.com.
