(correction: It should be Convert[J isinterface, T J]. I changed the name from I to J to be more readable and then missed one occurrence)
On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner <axel.wagner...@googlemail.com> wrote: > On Wed, Oct 4, 2023 at 6:54 AM Jon Watte <jwa...@gmail.com> wrote: > >> > where it is important to permit only type arguments that can be >> compared to nil >> >> I see! As in, if we somehow got a "equalszero" constraint, then that >> constraint would solve the problem I illustrate. >> I believe that assertion is correct, but I also believe that is a >> stronger assertion, and also that it introduces more of a new concept than >> a simple "nil" constraint. (Unless you're looking for some way to make >> "any" work, and introduce a zero keyword or something...) >> > > Yes, that is what #61372 <https://go.dev/issue/61372> proposes: Introduce > a `zero` predeclared identifier (!) that is assignable to any type and > comparable to any type. With some discussion about whether it should only > apply inside generic code or not. There is no proposal (as far as I know) > for anything like an "equalszero" constraint, as every type can be assigned > a meaningful comparison to its zero value, so it seems we should just allow > it for all types. > > To be clear, the criticism of a `nilable` constraint is > 1. It only solves a subset of the problem we are seeing. You gave examples > from that subset. I gave some examples of problems we are seeing that are > *not* in that subset. > 2. It is not really clear this particular subset is particularly > important. Why is the *specific* split into (interfaces, pointers, > slices, functions, maps, channels) and (numbers, booleans, strings, > structs, arrays) a particularly important one? > 3. As long as that is not clear, it seems more prudent to focus on > mechanisms that solve more of the problems we are seeing. > > FWIW I could, personally, get more (though still not fully) on board with > an `isinterface` constraint, that would allow *only* interfaces. It would > still allow assignment and comparison to `nil`. But it seems far clearer to > me, that interfaces can be singled out. While a `nil` interface is > categorically an invalid value, the same is not true for `nil` > pointers/maps/channels/funcs *in general*. Any of those kinds of types > could still have methods callable on them that work perfectly fine (by > doing an `if receiver == nil` check in the method). You categorically can't > call a method on a `nil` interface. > > And an `isinterface` constraint could still conceivable be useful for many > of the examples you mentioned. Or it would allow > > func Convert[J isinterface, T I](s []T) []J { > out := make([]I, len(T)) > for i, v := range s { > out[i] = J(v) > } > return out > } > > I'd still not be convinced this is really worth it, but at least it seems > clearer why that particular subset of types deserves to be singled out. In > fact, many people have argued that the interface zero value really > shouldn't have been spelled `nil`, because interfaces have so little in > common, conceptually, to other "nilable" types. > > >> >> Also, there's the ergonomics of having to make a zero value instance. >> Maybe we can rely on the compiler to optimize it away, but at a minimum it >> adds another required line of code in the implementation. E g: >> >> func MaybeNuke[T nil](b bool, val T) T { >> if b { >> return nil >> } >> return val >> } >> >> func MaybeNuke(T zero](b bool, val T) T { >> if b { >> var nope T // an extra line! >> return nope >> } >> return val >> } >> >> func MaybeNuke(T any](b bool, val T) T { >> if b { >> return zero[T]{} // maybe? seems weird >> } >> return val >> } >> >> This is because not all zero values can be instantiated inline with >> simply T{}. >> >> Sincerely, >> >> Jon Watte >> >> >> -- >> "I find that the harder I work, the more luck I seem to have." -- Thomas >> Jefferson >> > -- 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/CAEkBMfH0BdLrSjeBvV1sYoaPA13cJkpD-kyd5WOn8M32a2SnNw%40mail.gmail.com.
