On Mon, Dec 28, 2020 at 3:30 AM redsto...@gmail.com
<redstorm....@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.
>
> 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?
I think that one of the minimal requirements for any generics proposal
is the ability to write a Max function that works for variables (not
constants) of any integer or floating-point type. If we can't write
Max, then there are all sorts of useful functions that we can't write.
And since the predeclared types don't have methods, the approach you
describe doesn't permit us to write Max.
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/CAOyqgcV7Tv%2BceDXmpiry5K50MaZ%3DsgEO2%3Di-mShaNJHgBn9bOg%40mail.gmail.com.
