On Wednesday, 1 June 2022 at 08:49:50 UTC+1 axel.wa...@googlemail.com wrote:
> 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. > Yes, that's true - the zero value of string is defined to be "the empty string", regardless of what this means in terms of underlying pointer and len. And you can use foo == "" to test this. 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 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.
