On Mon, Aug 10, 2020 at 8:25 PM Ian Lance Taylor <i...@golang.org> wrote:
> On Mon, Aug 10, 2020 at 7:08 AM Markus Heukelom
> <markus.heuke...@gain.pro> wrote:
> >
> > Just a quick thought, instead of "comparable" (and type lists) maybe we
> could use a single operator to specify the required "operators" interface:
> >
> > type BiMap[type V, K ==] struct {
> > forward map[K]V
> > reverse map[V]K
> > }
> >
> > func Max[type T <](a, b T) T {
> >
> > }
> >
> > func ScanRowStruct[type T .](rows sql.Rows, dest *T) error { //
> operator . ensures T is a struct
> >
> > }
>
> It could probably work, but we wind up with a bunch of special purpose
> syntax with only a tenuous connection to the way constraints work in
> general. And you have to define connections between operators. That
> is, comparable supports both == and !=, but you only mentioned ==;
> does == imply !=?
>
>
I would even be in favor of not allowing any operations in generic code on
T (besides what is possible on all types), allowing T to carry data only*.
However, that's admittelly being too restrictive. You really do need to be
able to specify the requirement of == to support maps in structs**. No way
around it. The case of "<" is also strong for functions like max etc.
So you could maybe even say: you can specify one operator to use with T and
that's it (not even allowing interface{}-d constraints and not implying
other operators). That's the simplest thing that could possibly make it
work for maps, and most generic algorithms that are really wanted. Of
course "==" and "<" are just shorter ways for "comparable" and "ordered"
and have the slight advantage of not introducing new names in the global
namespace. But both would work.
-Markus
* To me, constraints on T are really complex especially because now you
have to choose whether to just use plain old interfaces or generics with
interface constraints when designing a solution. But being able to use T
instead of interface{} really helps in writing clear and type safe code.
It's the constraints that make it tricky for me.
** Assuming maps don't use !=
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/CAMoB8rVQNXo242jaU-wMZOdfTscTm-z8OGfys8giytg-BgnSWw%40mail.gmail.com.
