You are right. The implicit type conversion will bring confusion. I give
up. But I still think the type list is not a good idea. I'd rather not
support operators than use type list.
On Tuesday, December 29, 2020 at 1:51:13 PM UTC+8 Ian Lance Taylor wrote:
> On Mon, Dec 28, 2020 at 5:14 PM redsto...@gmail.com
> <redsto...@gmail.com> wrote:
> >
> > Constant here is just an example. We can use varaibles.
> > var a, b int
> > c := max(a,b)
> > on the base of type inference.
> > Predeclared types don't have methods.But we can extend the type
> restriction, using implicit type conversion here, between BiggerInt and
> int, BiggerFloat and float32.
> > I think the implicit type conversion here is better than type list in
> interface.
>
> You are suggesting that we have implicit type conversion from one
> defined type to another defined type, in order to add new methods?
>
> What if we have something like
>
> type MyInt int
>
> func (i MyInt) String() string { return fmt.Sprint(i) }
>
> func F(a, b MyInt) Myint {
> return Max(a, b)
> }
>
> Is that going to implicitly convert from MyInt to BiggerInt? Will the
> String method carry over?
>
> In general I would be quite nervous about implicit type conversion.
> It makes it very easy to get confused about what type you have and how
> that type changes. That is why Go has very little implicit type
> conversion.
>
> Ian
>
>
> > On Tuesday, December 29, 2020 at 1:35:37 AM UTC+8 Ian Lance Taylor wrote:
> >>
> >> On Mon, Dec 28, 2020 at 3: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.
> >> >
> >> > 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...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bff7f05e-e406-49c3-9c5b-e8404cbc7c4en%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/d913f752-fafe-4359-badd-d94cd3a5ee71n%40googlegroups.com.
