On Mon, Dec 28, 2020 at 7:10 PM redsto...@gmail.com
<redstorm....@gmail.com> wrote:
>
> 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.
If all you need is a method BiggerThan, then what you need is an
interface, not generics.
>
> 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.
--
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/CAMV2Rqo%2BkTQaDAWFc39dEcD6a%2B%2B%2BUizT62S02Uu14bDtApXo%3DQ%40mail.gmail.com.
