> Can you give us an example? I already gave examples! They're in the thread! In reality, we have the insides of a compiler where this would be helpful in more complex cases, and we have the insides of a graphql and JSON web interface where this would be helpful in a more complex case, but I'm not about to post the hundreds of lines of code that would be needed to set those up.
For another example, I have a slice of chans, some of which are nil. I'd like to compact that to only the non-nil chans. I can make a chan-specific slice compactor that's generic on the chan type. But why shouldn't I be able to also use that for errors, or maps, or pointers? Why do I need: func CompactChan[T any](ch []chan T) ... func CompactMap[K comparable, V any](m []map[K, V]) ... func CompactPointer[T any; U *T](sl []U) ... ... and this still can't be used on `[]error` (other than with explicit types, or using the more-powerful comparable constraint) The main problem here is that the language has a set of "comparable values" and a set of "comparable to nil" values and they only partially overlap. Because the language has a type semantic of "can be compared or assigned to nil," then that clearly should be expressible in the generic type system, unless you for some reason want the the generic type system to be deliberately less expressive than the full type system, and deliberately want to exclude use cases like these. Sincerely, Jon Watte -- "I find that the harder I work, the more luck I seem to have." -- Thomas Jefferson On Tue, Oct 3, 2023 at 5:32 PM Ian Lance Taylor <i...@golang.org> wrote: > On Tue, Oct 3, 2023 at 4:33 PM Jon Watte <jwa...@gmail.com> wrote: > > > > > > > > > It's not obvious that that is an interesting set of types. How often > > > do people want to write a generic function that permits any type that > > > can be compared to nil but does not permit any numeric or string type? > > > > Well I've run into this with some frequency, and a bunch of other > developers here have similarly moaned that this is a big gaping hole in the > constraint system. > > So, at least from our corner of the world, this is a legitimate desire. > > There's a few other questions like this on the internet, too, so I don't > think "we" are particularly special. > > Can you give us an example? There are clear reasons for being able to > compare a type to the zero value of that type. But it's not clear why > it's useful to focus on the set of types for which the zero value is > written as "nil". For example, why wouldn't I want to call your > LogJSON example with a string? Thanks. > > Ian > -- 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/CAJgyHGPjiKRLYp6OJ9%3DYXKkVzt2wipp2y4tpZjNgC1JGPD5r7A%40mail.gmail.com.
