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.
On Sunday, June 28, 2020 at 7:37:02 PM UTC+3, tdakkota 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.` > > > > > воскресенье, 28 июня 2020 г. в 06:13:31 UTC+3, 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. >> >> >> > -- 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/eea835d5-6773-41be-a7da-fa1807c5e504o%40googlegroups.com.
