This is increasingly off-topic (I don't have anything to add to the on-topic stuff itself), but.
On Thu, Jun 2, 2022 at 11:03 AM Brian Candler <b.cand...@pobox.com> wrote: > I wonder then why slice wasn't defined the same way - i.e. the zero value > of a slice could have been "empty slice". Today, empty slice and nil slice > are distinguishable - even if the empty slice has cap 0. > https://go.dev/play/p/L5d8rtvPJmz > > I guess the problem is deciding whether it's cap(x) == 0 or len(x) == 0 > which is the defining characteristic of the zero value. > I don't know why it was designed like that. I don't think this would have been a hard question, though. The important question is "what does a == nil do?", as that's the only thing that's different between them. So you could've just disallowed comparison to nil, requiring the programmer to be explicit. Just as with strings or most other types. If you would have wanted comparison with nil to work, you should have definitely made a==nil equivalent to cap(a)==0, as a slice with cap(a)>0 has behavioral differences to the zero value - e.g. a[:1] does not panic if cap(a)>0. In any case, it didn't end up that way. So by now the point is moot. 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 would work. Hence: > > if v == nil { ... } // v has zero value, regardless of its type > > v = nil // reset to zero value of its type > > return nil // zero value return > > 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. >> > > I believe the fundamental thing we're talking about here is the fact that > an interface value can be nil, or it can contain a typed value, which for > certain types may also happen to be nil. That issue isn't going away. The > question is, does this proposal make it any worse? > > The only thing you can do with interface values, apart from calling > methods on them, is to check their nilness. After doing Go for a while, I > realised that > > if abc == nil { ... } > > where "abc" is of an interface type, can only *possibly* be testing > whether the interface contains a value or not. It could not possibly be > testing the value inside the interface for nilness, because we have no idea > what type that is: e.g. it could be a struct, or a pointer to a struct, or > a named type based on int64, and not all of those are comparable to nil. > > Therefore, if all values became comparable to nil, then maybe people would > have a stronger reason for expecting "abc == nil" to act on the value > contained in the interface, rather than the interface itself. > > There have been various proposals to solve that. One is to have a > different constant for nil interface values, but then > > if err != nilinterface { ... } > > is fugly. You might as well introduce new syntax for testing nilness of > interfaces only: > > if has(err) { ... } > > if err.(any) { ... } > > Or even make interfaces (only) usable directly in boolean contexts: > > if err { ... } > > It would be a sort of half-way type assertion: this interface contains > some value, but I don't care what it is. It doesn't really solve the > underlying issue, but since you've not done an explicit comparison with > 'nil', maybe it's less surprising when you unwrap the value and find it > contains nil. > > -- > 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/aa57a605-512b-46e2-93da-2fbdfd5c4d41n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/aa57a605-512b-46e2-93da-2fbdfd5c4d41n%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/CAEkBMfH2iZYJfViTVGibcHKoiNUTzfb4S%2BnMT%3DcGAEGLz4GKDA%40mail.gmail.com.
