[generics] type list should not pass newtypes

[a b]

Newtype is a expression like

type MyInt int

It's not the same type as int, so why it's permitted?

In Go1 you must perform explicit conversion. 

For example,

type Float interface {

type float32, float64

}

func NewtonSqrt(type T Float)(v T) T {

var iterations int

switch (interface{})(v).(type) {

case float32:

iterations = 4

case float64:

iterations = 5

default:

panic("unreachable") // float cannot be nil, any other types are prohibited by type checker

}

// Code omitted.

}

type MyFloat float32

var myFloatValue MyFloat = MyFloat(64)

var G = NewtonSqrt(float32(myFloatValue)) // MyFloat is converted to float32 explicitly 

[Ian Lance Taylor]

On Sat, Jun 27, 2020 at 12:35 PM a b <tanc1...@gmail.com> wrote:
>
> Newtype is a expression like
> type MyInt int
>
> It's not the same type as int, so why it's permitted?
> In Go1 you must perform explicit conversion.

Because if you have a []MyInt, it would be nice to be able to pass
that to a function like slices.Min. Note that you can't directly
convert []MyInt to []int.

Ian

[tdakkota]

I think, if I want int/[]int, I should use int/[]int or just declare a domain specific alias.

MyInt/[]MyInt should implement Lesser/Min/etc interface. It can declare specific comparison rules.

Min implementation can be like: https://go2goplay.golang.org/p/Fgo2fJAlKXD (this code does not compile, I don't know why)

My point is that this decision is not Go1-like and can cause unexpected runtime errors.

суббота, 27 июня 2020 г. в 23:03:25 UTC+3, Ian Lance Taylor:

[Ian Lance Taylor]

On Sat, Jun 27, 2020 at 3:06 PM tdakkota <tanc1...@gmail.com> wrote:
>
> I think, if I want int/[]int, I should use int/[]int or just declare a domain specific alias.
> MyInt/[]MyInt should implement Lesser/Min/etc interface. It can declare specific comparison rules.
>
> Min implementation can be like: https://go2goplay.golang.org/p/Fgo2fJAlKXD (this code does not compile, I don't know why)
>
> My point is that this decision is not Go1-like and can cause unexpected runtime errors.

If we don't match on underlying types, then we can't use the <
operator on elements of a value of type []MyInt. Requiring people to
explicitly declare a Less method on an integer type seems like
unnecessary boilerplate that should be avoided. If we're going to do
that, why have type lists at all? Why not always require people to
declare a method?

Your example doesn't compile because Go doesn't have any conversion
from a slice of one type to a slice of a different type.

Go today has nothing like type lists. I don't agree that having type
lists match underlying types is not Go1-like, because I don't think
current Go has anything to say about type lists.

Ian

> суббота, 27 июня 2020 г. в 23:03:25 UTC+3, Ian Lance Taylor:
>>
>> On Sat, Jun 27, 2020 at 12:35 PM a b <tanc1...@gmail.com> wrote:
>> >
>> > Newtype is a expression like
>> > type MyInt int
>> >
>> > It's not the same type as int, so why it's permitted?
>> > In Go1 you must perform explicit conversion.
>>
>> Because if you have a []MyInt, it would be nice to be able to pass
>> that to a function like slices.Min. Note that you can't directly
>> convert []MyInt to []int.
>>
>> 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/5b246c09-e64b-47ff-b2ef-1c4f9ea7ea94n%40googlegroups.com.

[tdakkota]

When I say 'it's not Go-1like' I mean that MyInt type is not equal to int type in Go1 type system. 

reflect.DeepEqual(int(0), MyInt(0)) returns false.

Type assertion fails.

That's why I call it 'newtype'.

But type lists with non-interface types have a different logic. MyInt type is equal to int.

But, also, it requires explicit conversation to interface type: https://go2goplay.golang.org/p/2Ue3BlYBXyB. You cannot use underlying type as T Constr.  

It seems incorrect, when I write `type int` it means that only `int` should be permitted, not `MyInt/MySuperInt/etc.`

воскресенье, 28 июня 2020 г. в 06:13:31 UTC+3, Ian Lance Taylor:

[Viktor Kojouharov]

These type lists that are used in generic interfaces are not sum types. they are there to allow restrictions on operators, since only base types have operators in go (and types which use them as underlying types inherit). You are thinking of sum types, which go does not have.

[Ian Lance Taylor]

On Sun, Jun 28, 2020 at 9:37 AM tdakkota <tanc1...@gmail.com> wrote:
>
> When I say 'it's not Go-1like' I mean that MyInt type is not equal to int type in Go1 type system.
> reflect.DeepEqual(int(0), MyInt(0)) returns false.
> Type assertion fails.
> That's why I call it 'newtype'.
>
> But type lists with non-interface types have a different logic. MyInt type is equal to int.
> But, also, it requires explicit conversation to interface type: https://go2goplay.golang.org/p/2Ue3BlYBXyB. You cannot use underlying type as T Constr.
> It seems incorrect, when I write `type int` it means that only `int` should be permitted, not `MyInt/MySuperInt/etc.`

I think I've explained why it is really essential that we be able to
match on underlying types.

If you feel that type lists should only match on identical types, then
what do you suggest we should use to match on underlying types? Then
perhaps we can do that, and remove type lists. I'm somewhat
sympathetic to the goal, but type lists matching on underlying types
are the best idea we've had so far. We can't just start matching on
identical types only. That won't be satisfactory, as I've tried to
explain.

Thanks.

Ian

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e21310a0-d7b4-4c2e-9b6d-8ff8530522b8n%40googlegroups.com.