On Tue, Jun 16, 2020 at 9:54 PM Bakul Shah <ba...@iitbombay.org> wrote: > > Seems to me that perhaps 'ordered' should also be *predeclared*. > What happens if/when a big int type is added in future? Or > decimal or big floats. "The Expression Problem" comes to mind :-)
Adding new predeclared types is sure to be rare. If we want to predeclare constraints like "ordered", we have to consider all other possible type combinations that people might want. And it turns out that there are quite a few, like 25. That's why we suggested type lists: because it will always work for any combination of types that people might want, and we don't have to add 25 new predeclared names. > It would be nice if it was possible to extend operators for user > defined types (but I suspect people will object!). If syntax for > such existed, both 'ordered' and 'comparable' could be defined > cleanly. Yes. > I don't really see very many uses of an interface containing a > list of types. Not many, but non-zero. And it seems clearly essential to permit people to write generic functions that use operators like "<" and "+". > Finally how would generics defined using 'ordered' deal with NaNs? > NaNs are unordered! See, e.g., https://go.googlesource.com/go/+/refs/heads/dev.go2go/src/cmd/go2go/testdata/go2path/src/slices/slices.go2#14 . 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/CAOyqgcXUnkm5eCB2Eo%3Dk4yOvyiimJrLou-V4bOT_7GNuJnPG7A%40mail.gmail.com.
