On Wed, Jun 1, 2022 at 9:05 AM Brian Candler <b.cand...@pobox.com> wrote:
> On Wednesday, 1 June 2022 at 02:19:43 UTC+1 Ian Lance Taylor wrote: > >> We could do that. The main concern is that "nil" is already >> overloaded, and people new to Go are frequently confused by it. See >> the FAQ entry https://go.dev/doc/faq#nil_error . Adding more uses of >> nil will increase the potential for confusion. >> > > I think this is an interesting proposal. If "nil" were to mean "the zero > value of *any* type" then you can argue it removes a layer of confusion. > Not only is it the zero value for pointers, interfaces, slices, maps and > channels, but also for strings, integers, structs, and anything else that > comes along. > > Where confusion might arise is in the operations on nil. It's already > weird that nil slices and zero-length slices are distinguishable: > https://go.dev/play/p/6MVECg4onAk > > We'd then end up in the same position with strings, depending on how > exactly the nil value of a string is defined: > I don't think we *could* define it in that way. The zero value of a string must always be identical to the empty string, so as to not break existing code. That is, `nil` would become a way to write "", effectively. > There would be an incentive for Go APIs to treat nil strings and empty > strings differently (especially in SQL, JSON/YAML etc), and that would > certainly be a bad thing IMO. > > And you might get some other strange stuff, like being able to do > arithmetic on nil. > > a := 3 > b := a + nil // b := a + 0 ?? > var c float64 = nil + nil // ??? > Theoretically, that depends on how this was actually done. Currently, the pre-declared identifier `nil` is not actually a value, as such. The spec treats it as a special case for comparisons <https://go.dev/ref/spec#Comparison_operators> and assignability <https://go.dev/ref/spec#Assignability>, for example. I think we would have to continue making it a special case in many if not most aspects. It might be tempting to define `nil` as an untyped constant, but then we'd have to give it a default type and there does not seem to be a good option. I think if we'd a) made the predeclared identifier `nil` assignable to any type and b) expanded the special case for comparisons to all types, we'd get the desired effect without allowing arithmetic expressions like these. That being said, I also don't see a lot of harm in allowing them, if we make `nil` represent the zero value of any type. It is true that the code reads strangely, but we don't have to disallow all strange code. Lastly, with all this in mind: I agree with Ian that overloading `nil` further is probably not good, even though we could. Most questions about it come in the form of "That function returns nil, but if I compare to nil it's false", or "I get a nil-pointer exception, but I checked for nil right before that" and those definitely wouldn't get any less confusing. > -- > 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/7292a481-af17-49a3-b887-93ab55c35bcen%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/7292a481-af17-49a3-b887-93ab55c35bcen%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfGMXVRZCvuQ-RqGXLiib9YJcf3qYgvtyxKDah4fGuA%2BtQ%40mail.gmail.com.
