But interface-only contracts do work here, as I suggest, only need to
introduce implicit type conversion. Type list is not so good as you say.
When defining the generic funcition max, I am not expecting number and
string, and I am not expecting operator>, I am expecting method
BiggerThan. Using methods keeps consistency of the language, and it is much
more clear than type list and operators. Type list is strange in the
interface with methods, and causes a lot of other problems. This solution
only adds complexity in generic libraries. But the type list invades in the
language core. So far as I can see, the implicit type conversion is
better, at least it can be considered. If there is technical difficulty on
the implicit type conversion, we can discuss it.
On Tuesday, December 29, 2020 at 12:19:49 AM UTC+8 bbse...@gmail.com wrote:
> On Mon, Dec 28, 2020 at 4:30 AM redsto...@gmail.com
> <redsto...@gmail.com> wrote:
> >
> > If generic is inevitable, make it better. The type list in the current
> draft is so special that it is added only for operators. I think it will
> bring complexity and inconsistens in go. So I get an idea to replace it.
>
> There have been similar proposals before. Interface-only contracts do
> not work for primitive types, as you realized, so there were
> suggestions to work around that limitation, as you already did.
>
> I believe the question you should ask is that in a language with no
> operator overloading, what is the purpose of defining a constraint
> that allows operator >? That simply means numeric types and string. I
> think it is much more concise and explicit to say "the function
> expects a numeric or string" than to say "the function expects a type
> on which > can be used".
>
> >
> > type bigger[T bigger] interface{
> > BiggerThan(T) bool
> > }
> >
> > func max[T bigger[T]](a, b T) T{
> > if a.BiggerThan(b) {
> > return a
> > } else {
> > return b
> > }
> > }
> >
> > type BiggerInt int
> >
> > func (a BiggerInt) BiggerThan(b BiggerInt)bool{
> > return a > b
> > }
> >
> > type BiggerFloat float32
> >
> > func (a BiggerFloat) BiggerThan(b BiggerFloat)bool{
> > return a > b
> > }
> >
> >
> > max(1,2)
> >
> > instead of operators we use method. the generic call site remain the
> same.
> > If we allow the implicity type conversion between BiggerInt and int,
> this will work.
> >
> > This solution will write more code when we define BiggerThan in each
> type. But we remove type list in interface. How do you think it?
> >
> > --
> > 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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/debe7749-fe96-4587-814b-a76ee7f48528n%40googlegroups.com
> .
>
--
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/3aa54c64-b76e-4ccf-bbf2-b42c3c12d24fn%40googlegroups.com.
