On Mon, Dec 28, 2020 at 5:14 PM redsto...@gmail.com
<redstorm....@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+unsubscr...@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/CAOyqgcUo88WGQdU0%2BhgbE7sWczyBMoVrHhym8NUVv7Fa26vN6w%40mail.gmail.com.
