[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

Oops, I meant "all interfaces can be used as a constraint yet there are 
interfaces that can be used as a value's type"

-- 
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/c0d414a5-070a-4e2b-8ebe-9f375d719ec6n%40googlegroups.com.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

> But I don't think that using type list constraint as sum types is good 
idea.
> Type constraints should be known in compile-time, but the sum type 
variant should be known in run-time.

It looks like you misunderstand it a bit. Indeed

type Constraint interface {
type Type₁, Type₂, …, Typeₙ
}

was introduced as a meta-construct. Some people, including me, were not 
particularly happy about it, as it
cannot be used as a value type and assymetry appears: all interfaces can be 
used as a constraint yet there
are interfaces that can't. An obvious inconsistency. So, they (the Go team) 
addressed this with an idea to
utilize such kind of interfaces for runtime values as a sum type.

I really wish they make it into Go together with generics too. Some parts 
of my code would finally be
straightforward.

пятница, 4 сентября 2020 г. в 21:45:48 UTC+3, tdakkota: 

> I'd like to see sum types in Go2 and there are many reasons: 
> - It can make using oneOf/anyOf in protobuf or swagger mush easier.
> - It can make ast.Node type-safe. 
> - With sum-types compiler known maximum size of variant, so it can be 
> allocated on stack, not on heap.
>
> But I don't think that using type list constraint as sum types is good 
> idea.
> Type constraints should be known in compile-time, but the sum type variant 
> should be known in run-time.
> пятница, 21 августа 2020 г. в 03:28:23 UTC+3, Ian Lance Taylor: 
>
>> After many discussions and reading many comments, we plan to move 
>> forward with some changes and clarifications to the generics design 
>> draft. 
>>
>> 1. 
>>
>> We’re going to settle on square brackets for the generics syntax. 
>> We’re going to drop the “type” keyword before type parameters, as 
>> using square brackets is sufficient to distinguish the type parameter 
>> list from the ordinary parameter list. To avoid the ambiguity with 
>> array declarations, we will require that all type parameters provide a 
>> constraint. This has the advantage of giving type parameter lists the 
>> exact same syntax as ordinary parameter lists (other than using square 
>> brackets). To simplify the common case of a type parameter that has 
>> no constraints, we will introduce a new predeclared identifier “any” 
>> as an alias for “interface{}”. 
>>
>> The result is declarations that look like this: 
>>
>> type Vector[T any] []T 
>> func Print[T any](s []T) { … } 
>> func Index[T comparable](s []T, e T) { … } 
>>
>> We feel that the cost of the new predeclared identifier “any” is 
>> outweighed by the simplification achieved by making all parameter 
>>
> lists syntactically the same: as each regular parameter always has a 
>> type, each type parameter always has a constraint (its meta-type). 
>>
>> Changing “[type T]” to “[T any]” seems about equally readable and 
>> saves one character. We’ll be able to streamline a lot of existing 
>> code in the standard library and elsewhere by replacing “interface{}” 
>> with “any”. 
>>
>> 2. 
>>
>> We’re going to simplify the rule for type list satisfaction. The type 
>> argument will satisfy the constraint if the type argument is identical 
>> to any type in the type list, or if the underlying type of the type 
>> argument is identical to any type in the type list. What we are 
>> removing here is any use of the underlying types of the types in the 
>> type list. This tweaked rule means that the type list can decide 
>> whether to accept an exact defined type, other than a predeclared 
>> type, or whether to accept any type with a matching underlying type. 
>>
>> This is a subtle change that we don’t expect to affect any existing 
>> experimental code. 
>>
>> We think that this definition might work if we permit interface types 
>> with type lists to be used outside of type constraints. Such 
>> interfaces would effectively act like sum types. That is not part of 
>> this design draft, but it’s an obvious thing to consider for the 
>> future. 
>>
>> Note that a type list can mention type parameters (that is, other type 
>> parameters in the same type parameter list). These will be checked by 
>> first replacing the type parameter(s) with the corresponding type 
>> argument(s), and then using the rule described above. 
>>
>> 3. 
>>
>> We’re going to clarify that when considering the operations permitted 
>> for a value whose type is a type parameter, we will ignore the methods 
>> of any types in the type list. The general rule is that the generic 
>> function can use any operation permitted by every type in the type 
>> list. However, this will only apply to operators and predeclared 
>> functions (such as "len" and "cap"). It won’t apply to methods, for 
>> the case where the type list includes a list of types that all define 
>> some method. Any methods must be listed separately in the interface 
>> type, not inherited from the type list. 
>>
>> This rule seems generally clear, and avoids some complex reasoning 
>> involving type lists that include structs with embedded type 
>> 

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[tdakkota]

I'd like to see sum types in Go2 and there are many reasons: 
- It can make using oneOf/anyOf in protobuf or swagger mush easier.
- It can make ast.Node type-safe. 
- With sum-types compiler known maximum size of variant, so it can be 
allocated on stack, not on heap.

But I don't think that using type list constraint as sum types is good idea.
Type constraints should be known in compile-time, but the sum type variant 
should be known in run-time.
пятница, 21 августа 2020 г. в 03:28:23 UTC+3, Ian Lance Taylor: 

> After many discussions and reading many comments, we plan to move
> forward with some changes and clarifications to the generics design
> draft.
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary parameter list. To avoid the ambiguity with
> array declarations, we will require that all type parameters provide a
> constraint. This has the advantage of giving type parameter lists the
> exact same syntax as ordinary parameter lists (other than using square
> brackets). To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.
>
> The result is declarations that look like this:
>
> type Vector[T any] []T
> func Print[T any](s []T) { … }
> func Index[T comparable](s []T, e T) { … }
>
> We feel that the cost of the new predeclared identifier “any” is
> outweighed by the simplification achieved by making all parameter
> lists syntactically the same: as each regular parameter always has a
> type, each type parameter always has a constraint (its meta-type).
>
> Changing “[type T]” to “[T any]” seems about equally readable and
> saves one character. We’ll be able to streamline a lot of existing
> code in the standard library and elsewhere by replacing “interface{}”
> with “any”.
>
> 2.
>
> We’re going to simplify the rule for type list satisfaction. The type
> argument will satisfy the constraint if the type argument is identical
> to any type in the type list, or if the underlying type of the type
> argument is identical to any type in the type list. What we are
> removing here is any use of the underlying types of the types in the
> type list. This tweaked rule means that the type list can decide
> whether to accept an exact defined type, other than a predeclared
> type, or whether to accept any type with a matching underlying type.
>
> This is a subtle change that we don’t expect to affect any existing
> experimental code.
>
> We think that this definition might work if we permit interface types
> with type lists to be used outside of type constraints. Such
> interfaces would effectively act like sum types. That is not part of
> this design draft, but it’s an obvious thing to consider for the
> future.
>
> Note that a type list can mention type parameters (that is, other type
> parameters in the same type parameter list). These will be checked by
> first replacing the type parameter(s) with the corresponding type
> argument(s), and then using the rule described above.
>
> 3.
>
> We’re going to clarify that when considering the operations permitted
> for a value whose type is a type parameter, we will ignore the methods
> of any types in the type list. The general rule is that the generic
> function can use any operation permitted by every type in the type
> list. However, this will only apply to operators and predeclared
> functions (such as "len" and "cap"). It won’t apply to methods, for
> the case where the type list includes a list of types that all define
> some method. Any methods must be listed separately in the interface
> type, not inherited from the type list.
>
> This rule seems generally clear, and avoids some complex reasoning
> involving type lists that include structs with embedded type
> parameters.
>
> 4.
>
> We’re going to permit type switches on type parameters that have type
> lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> clarify code like “switch v := x.(type)”. A type switch on a type
> parameter won’t be able to use the “:=” syntax anyhow, so there is no
> reason to require “.(type)”. In a type switch on a type parameter
> with a type list, every case listed must be a type that appears in the
> type list (“default” is also permitted, of course). A case will be
> chosen if it is the type matched by the type argument, although as
> discussed above it may not be the exact type argument: it may be the
> underlying type of the type argument. To make that rule very clear,
> type switches will not be permitted for type parameters that do not
> have type lists. It is already possible to switch on a value “x”
> whose type is a type parameter without a type list by writing code
> like “switch (interface{})(x).(type)” (which may now be written as
> “switch any(x).(type)”). That 

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Nishanth Shanmugham]

After thinking about this more last evening and reading code in the new
style, I've changed my mind.
I think my previous feedback was too influenced by the fact that I disliked
a new predeclared identifier being introduced, and that the style was
different from what I'm used to in TypeScript/Java.

I'm now liking the uniformity and the explicitness.

> In general, a language that's easier to parse mechanically is also easier
to parse by a human.

Good point, and I now agree that it's the case here. I also like that
requiring any/interface{} explicitly removes the confusion in code such as:

func Print[T, S Stringer]()

because "T, S Stringer" in non-type parameters means that T, S are both
type Stringer, but is confusing in type parameters (namely, is T any or
Stringer?).

> So, assuming the first one isn't an option, do you still find the last
one preferable over the second one?

I prefer the second one, [T any]/[T Foo].

On Wed, Sep 2, 2020 at 11:19 PM Axel Wagner 
wrote:

> On Wed, Sep 2, 2020 at 7:02 PM Nishanth Shanmugham <
> nishanth.gerr...@gmail.com> wrote:
>
>> If it is intended at simplification for parsers, […] If it is intended to
>> improve readability for readers of generic code
>>
>
> I would argue that this is not a dichotomy. On the contrary: In general, a
> language that's easier to parse mechanically is also easier to parse by a
> human. The converse isn't always true, but still, optimizing for mechanical
> parsers also tends to help humans.
>
>
>> I think that the opposite is happening. Writing `any/interface{}` for a
>> non-constrained type adds more clutter than it contributes to reading
>> uniformity. It is common in languages such as TypeScript and Java for a
>> non-constrained type to be simply written as "T", which in my experience,
>> has been readable and clutter-free.
>>
>
> The choice isn't really between writing
> [T]/[T Foo],
> or writing
> [T any]/[T Foo].
> It's between the latter and
> [type T]/[type T Foo].
>
> So, assuming the first one isn't an option, do you still find the last one
> preferable over the second one?
>
>
>> On Monday, August 31, 2020 at 11:04:17 PM UTC+5:30 Ian Lance Taylor wrote:
>>
>>> On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com
>>>  wrote:
>>> >
>>> > Great improvements. Well done.
>>> >
>>> > Any intentions to make methods accept additional type arguments ?
>>>
>>> See
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
>>> .
>>>
>>> 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/269b0470-d197-4a7d-af37-bec63e27ef10n%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/CABX8%3DwfhCJOtvmsOi3ePhEa5z0CwBZE63J81eMYXZmd5fSeN5g%40mail.gmail.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

['Axel Wagner' via golang-nuts]

On Wed, Sep 2, 2020 at 7:02 PM Nishanth Shanmugham <
nishanth.gerr...@gmail.com> wrote:

> If it is intended at simplification for parsers, […] If it is intended to
> improve readability for readers of generic code
>

I would argue that this is not a dichotomy. On the contrary: In general, a
language that's easier to parse mechanically is also easier to parse by a
human. The converse isn't always true, but still, optimizing for mechanical
parsers also tends to help humans.


> I think that the opposite is happening. Writing `any/interface{}` for a
> non-constrained type adds more clutter than it contributes to reading
> uniformity. It is common in languages such as TypeScript and Java for a
> non-constrained type to be simply written as "T", which in my experience,
> has been readable and clutter-free.
>

The choice isn't really between writing
[T]/[T Foo],
or writing
[T any]/[T Foo].
It's between the latter and
[type T]/[type T Foo].

So, assuming the first one isn't an option, do you still find the last one
preferable over the second one?


> On Monday, August 31, 2020 at 11:04:17 PM UTC+5:30 Ian Lance Taylor wrote:
>
>> On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com
>>  wrote:
>> >
>> > Great improvements. Well done.
>> >
>> > Any intentions to make methods accept additional type arguments ?
>>
>> See
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
>> .
>>
>> 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/269b0470-d197-4a7d-af37-bec63e27ef10n%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/CAEkBMfG9p71gh0yt9fG3cvNkz8YBwdPfJb4BgJd2sBHFge9KJg%40mail.gmail.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Nishanth Shanmugham]

Some feedback on requiring any/interface{} explicitly.

> We feel that the cost of the new predeclared identifier “any” is 
outweighed by the simplification achieved by making all parameter 
lists syntactically the same

Why is this simplification preferred? If it is intended at simplification 
for parsers,  I think that on its own it does not warrant the addition of a 
new predeclared identifier to the language spec. (We should rather do the 
extra work in the parsers.) 

If it is intended to improve readability for readers of generic code, I 
think that the opposite is happening. Writing `any/interface{}` for a 
non-constrained type adds more clutter than it contributes to reading 
uniformity. It is common in languages such as TypeScript and Java for a 
non-constrained type to be simply written as "T", which in my experience, 
has been readable and clutter-free.

On Monday, August 31, 2020 at 11:04:17 PM UTC+5:30 Ian Lance Taylor wrote:

> On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com
>  wrote:
> >
> > Great improvements. Well done.
> >
> > Any intentions to make methods accept additional type arguments ?
>
> See 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
> .
>
> 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/269b0470-d197-4a7d-af37-bec63e27ef10n%40googlegroups.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Ian Lance Taylor]

On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com
 wrote:
>
> Great improvements. Well done.
>
> Any intentions to make methods accept additional type arguments ?

See 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
.

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/CAOyqgcVNjM1jzLQH6isUJyvh8oVj4Ciw-5FxMXfgnWeiOj2yjw%40mail.gmail.com.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[samir.el...@gmail.com]

Great improvements. Well done.

Any intentions to make methods accept additional type arguments ?

On Friday, August 21, 2020 at 2:28:23 AM UTC+2 Ian Lance Taylor wrote:

> After many discussions and reading many comments, we plan to move
> forward with some changes and clarifications to the generics design
> draft.
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary parameter list. To avoid the ambiguity with
> array declarations, we will require that all type parameters provide a
> constraint. This has the advantage of giving type parameter lists the
> exact same syntax as ordinary parameter lists (other than using square
> brackets). To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.
>
> The result is declarations that look like this:
>
> type Vector[T any] []T
> func Print[T any](s []T) { … }
> func Index[T comparable](s []T, e T) { … }
>
> We feel that the cost of the new predeclared identifier “any” is
> outweighed by the simplification achieved by making all parameter
> lists syntactically the same: as each regular parameter always has a
> type, each type parameter always has a constraint (its meta-type).
>
> Changing “[type T]” to “[T any]” seems about equally readable and
> saves one character. We’ll be able to streamline a lot of existing
> code in the standard library and elsewhere by replacing “interface{}”
> with “any”.
>
> 2.
>
> We’re going to simplify the rule for type list satisfaction. The type
> argument will satisfy the constraint if the type argument is identical
> to any type in the type list, or if the underlying type of the type
> argument is identical to any type in the type list. What we are
> removing here is any use of the underlying types of the types in the
> type list. This tweaked rule means that the type list can decide
> whether to accept an exact defined type, other than a predeclared
> type, or whether to accept any type with a matching underlying type.
>
> This is a subtle change that we don’t expect to affect any existing
> experimental code.
>
> We think that this definition might work if we permit interface types
> with type lists to be used outside of type constraints. Such
> interfaces would effectively act like sum types. That is not part of
> this design draft, but it’s an obvious thing to consider for the
> future.
>
> Note that a type list can mention type parameters (that is, other type
> parameters in the same type parameter list). These will be checked by
> first replacing the type parameter(s) with the corresponding type
> argument(s), and then using the rule described above.
>
> 3.
>
> We’re going to clarify that when considering the operations permitted
> for a value whose type is a type parameter, we will ignore the methods
> of any types in the type list. The general rule is that the generic
> function can use any operation permitted by every type in the type
> list. However, this will only apply to operators and predeclared
> functions (such as "len" and "cap"). It won’t apply to methods, for
> the case where the type list includes a list of types that all define
> some method. Any methods must be listed separately in the interface
> type, not inherited from the type list.
>
> This rule seems generally clear, and avoids some complex reasoning
> involving type lists that include structs with embedded type
> parameters.
>
> 4.
>
> We’re going to permit type switches on type parameters that have type
> lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> clarify code like “switch v := x.(type)”. A type switch on a type
> parameter won’t be able to use the “:=” syntax anyhow, so there is no
> reason to require “.(type)”. In a type switch on a type parameter
> with a type list, every case listed must be a type that appears in the
> type list (“default” is also permitted, of course). A case will be
> chosen if it is the type matched by the type argument, although as
> discussed above it may not be the exact type argument: it may be the
> underlying type of the type argument. To make that rule very clear,
> type switches will not be permitted for type parameters that do not
> have type lists. It is already possible to switch on a value “x”
> whose type is a type parameter without a type list by writing code
> like “switch (interface{})(x).(type)” (which may now be written as
> “switch any(x).(type)”). That construct is not the simplest, but it
> uses only features already present in the language, and we don’t
> expect it to be widely needed.
>
>
> These changes will soon be implemented in the experimental design on
> the dev.generics branch, and in the go2go playground. Some of them
> already work. We will update the design draft accordingly.
>
>

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[adonovan via golang-nuts]

On Thursday, 20 August 2020 20:28:23 UTC-4, Ian Lance Taylor wrote:

> We’re going to settle on square brackets for the generics syntax.


FWIW, the same square-bracket syntax was used by Barbara Liskov's CLU in 
the mid-1970s, and was, as far as I can tell, the first syntax used for 
parametric polymorphism in an ALGOL-like language. The Greek prefix 
notation (e.g. *α *list) used by its contemporary, ML, appears to have 
originated in Christopher Strachey's 1968 lecture notes. C++'s 
angle-bracket templates didn't appear until the 1980s, along with ADAs, 
which used ordinary parens, as in your earlier proposal.





-- 
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/d8091421-4c9e-4f86-b883-1d0744d08480o%40googlegroups.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[roger peppe]

On Mon, 24 Aug 2020 at 12:57, 'Richard Oudkerk' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

>
> Applying the same rule to type lists and type switches you should be able
> to write
>
> type Comparer[T any] interface {
> Compare(T) int
> }
>
> type CompareConstraints interface {
> type int, int8, …, float64, string, Comparer
> }
>
> func Min[T CompareConstraints](x, y T) bool {
> switch T {
> case int:
> …
> …
> case Comparer:
> if x.Compare(y) < 0 {
> return x
> }
> return y
> }
> }
>
> But the current proposal does not allow interfaces in type lists.
>

FWIW, even if the proposal did allow interfaces in type lists, you wouldn't
be able to invoke the Compare method on x, because both:
a) the allowed operations on T are the intersection of all the operations
in the type list, and only one of those types has a Compare method
and
b) according to the first post in this thread, methods are specifically
excluded from the operations allowed by a type list.


> On Monday, 24 August 2020 at 07:09:15 UTC+1 rog wrote:
>
>> On Mon, 24 Aug 2020 at 06:35, Denis Cheremisov 
>> wrote:
>>
>>> I probably didn't read what you have wrote in the first message carefuly
>>> enough. Does it mean something like that will work
>>>
>>> type SomeTypes interface {
>>> type int, float32, float64
>>> }
>>>
>>> func Min[T SomeTypes](x, y T) T {
>>> switch T {
>>> case int:
>>> if x < y {
>>> return x
>>> }
>>> return y
>>> case float32:
>>> return math.Min(float64(x), float64(y))
>>> case float64:
>>> return math.Min(x, y)
>>> }
>>> }
>>>
>>
>> This was discussed above.
>>
>> I don't believe you can do that. I didn't see any suggestion that knowing
>> the type implies the ability
>> to convert from the generic type to the known underlying type.
>>
>>>
>>> Would something like below work as well?
>>>
>>> type Compare[T any] interface {
>>> Compare(x, y T) int
>>> }
>>>
>>> type CompareConstraints[T any] {
>>> type int, int8, …, float64, string, Compare[T]
>>> }
>>>
>>> func Min[T CompareConstraints]Min(x, y T) bool {
>>> switch T {
>>> case int:
>>> …
>>> …
>>> case Compare[T]:
>>> return x.Compare(y) < 0
>>> }
>>> }
>>>
>>
>> No. As proposed, the type switch doesn't change anything about the type T.
>>
>> Also, AIUI that type list wouldn't be very useful in practice, because
>> using that interface type in the type list would only allow types whose
>> underlying type is exactly Compare[T], which doesn't include any
>> non-interface types or interface types that have more methods than just
>> Compare.
>>
>>   cheers,
>> rog.
>>
>> --
> 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/03342d1f-5c82-40e6-98fc-18e95bfd183cn%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/CAJhgacgSS%2B1p9Z3r7iCm8jDGgVyEW0zA2La%3DwBJkZaGz%2BsuWew%40mail.gmail.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

['Richard Oudkerk' via golang-nuts]

The current proposal says 



*The rule is that if a type contraint has a single type parameter, and it 
is used in a function's type parameter list without an explicit type 
argument, then the type argument is the type parameter being constrained.*

That means you can write

type Comparer[T any] interface {
Compare(T) int
}

func Min[T Comparer](x, y T) bool {
if x.Compare(y) < 0 {
return x
}
return y
}

Applying the same rule to type lists and type switches you should be able 
to write

type Comparer[T any] interface {
Compare(T) int
}

type CompareConstraints interface {
type int, int8, …, float64, string, Comparer
}

func Min[T CompareConstraints](x, y T) bool {
switch T {
case int:
…
…
case Comparer:
if x.Compare(y) < 0 {
return x
}
return y
}
}

But the current proposal does not allow interfaces in type lists.
On Monday, 24 August 2020 at 07:09:15 UTC+1 rog wrote:

> On Mon, 24 Aug 2020 at 06:35, Denis Cheremisov  
> wrote:
>
>> I probably didn't read what you have wrote in the first message carefuly 
>> enough. Does it mean something like that will work
>>
>> type SomeTypes interface {
>> type int, float32, float64
>> }
>>
>> func Min[T SomeTypes](x, y T) T {
>> switch T {
>> case int:
>> if x < y {
>> return x
>> }
>> return y
>> case float32:
>> return math.Min(float64(x), float64(y))
>> case float64:
>> return math.Min(x, y)
>> }
>> }
>>
>  
> This was discussed above.
>
> I don't believe you can do that. I didn't see any suggestion that knowing 
> the type implies the ability
> to convert from the generic type to the known underlying type.
>
>>
>> Would something like below work as well?
>>
>> type Compare[T any] interface {
>> Compare(x, y T) int
>> }
>>
>> type CompareConstraints[T any] {
>> type int, int8, …, float64, string, Compare[T]
>> }
>>
>> func Min[T CompareConstraints]Min(x, y T) bool {
>> switch T {
>> case int:
>> …
>> …
>> case Compare[T]:
>> return x.Compare(y) < 0
>> }
>> }
>>
>
> No. As proposed, the type switch doesn't change anything about the type T.
>
> Also, AIUI that type list wouldn't be very useful in practice, because 
> using that interface type in the type list would only allow types whose 
> underlying type is exactly Compare[T], which doesn't include any 
> non-interface types or interface types that have more methods than just 
> Compare.
>
>   cheers,
> rog.
>
>

-- 
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/03342d1f-5c82-40e6-98fc-18e95bfd183cn%40googlegroups.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Juliusz Chroboczek]

>> Could you please give an example of the proposed syntax?

> func F[T constraints.Integer]() {
> switch T {
> case int:
> case int8:
> }
> }

Makes perfect sense, thanks.

-- 
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/877dtofltb.wl-jch%40irif.fr.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Anderson Queiroz]

I liked the 'any' idea. It always felt to me a bit odd/not so clear 
interface{} means anything.

Still, interfaces with type parameters for non generic code seems a mix of 
behaviour and implementation description.

In all, looking forward to see these changes implemented to try them out :)

On Monday, 24 August 2020 at 08:09:15 UTC+2 rog wrote:

> On Mon, 24 Aug 2020 at 06:35, Denis Cheremisov  
> wrote:
>
>> I probably didn't read what you have wrote in the first message carefuly 
>> enough. Does it mean something like that will work
>>
>> type SomeTypes interface {
>> type int, float32, float64
>> }
>>
>> func Min[T SomeTypes](x, y T) T {
>> switch T {
>> case int:
>> if x < y {
>> return x
>> }
>> return y
>> case float32:
>> return math.Min(float64(x), float64(y))
>> case float64:
>> return math.Min(x, y)
>> }
>> }
>>
>  
> This was discussed above.
>
> I don't believe you can do that. I didn't see any suggestion that knowing 
> the type implies the ability
> to convert from the generic type to the known underlying type.
>
>>
>> Would something like below work as well?
>>
>> type Compare[T any] interface {
>> Compare(x, y T) int
>> }
>>
>> type CompareConstraints[T any] {
>> type int, int8, …, float64, string, Compare[T]
>> }
>>
>> func Min[T CompareConstraints]Min(x, y T) bool {
>> switch T {
>> case int:
>> …
>> …
>> case Compare[T]:
>> return x.Compare(y) < 0
>> }
>> }
>>
>
> No. As proposed, the type switch doesn't change anything about the type T.
>
> Also, AIUI that type list wouldn't be very useful in practice, because 
> using that interface type in the type list would only allow types whose 
> underlying type is exactly Compare[T], which doesn't include any 
> non-interface types or interface types that have more methods than just 
> Compare.
>
>   cheers,
> rog.
>
>

-- 
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/64cb4261-5567-451e-b98a-5792b3adc36fn%40googlegroups.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[roger peppe]

On Mon, 24 Aug 2020 at 06:35, Denis Cheremisov 
wrote:

> I probably didn't read what you have wrote in the first message carefuly
> enough. Does it mean something like that will work
>
> type SomeTypes interface {
> type int, float32, float64
> }
>
> func Min[T SomeTypes](x, y T) T {
> switch T {
> case int:
> if x < y {
> return x
> }
> return y
> case float32:
> return math.Min(float64(x), float64(y))
> case float64:
> return math.Min(x, y)
> }
> }
>

This was discussed above.

I don't believe you can do that. I didn't see any suggestion that knowing
the type implies the ability
to convert from the generic type to the known underlying type.

>
> Would something like below work as well?
>
> type Compare[T any] interface {
> Compare(x, y T) int
> }
>
> type CompareConstraints[T any] {
> type int, int8, …, float64, string, Compare[T]
> }
>
> func Min[T CompareConstraints]Min(x, y T) bool {
> switch T {
> case int:
> …
> …
> case Compare[T]:
> return x.Compare(y) < 0
> }
> }
>

No. As proposed, the type switch doesn't change anything about the type T.

Also, AIUI that type list wouldn't be very useful in practice, because
using that interface type in the type list would only allow types whose
underlying type is exactly Compare[T], which doesn't include any
non-interface types or interface types that have more methods than just
Compare.

  cheers,
rog.

-- 
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/CAJhgachjLex%3DUNP_trPy55mNcn3iXNePYE8pFOuA1oLa2GJ9Xw%40mail.gmail.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Denis Cheremisov]

I probably didn't read what you have wrote in the first message carefuly 
enough. Does it mean something like that will work

type SomeTypes interface {
type int, float32, float64
}

func Min[T SomeTypes](x, y T) T {
switch T {
case int:
if x < y {
return x
}
return y
case float32:
return math.Min(float64(x), float64(y))
case float64:
return math.Min(x, y)
}
}

Would something like below work as well?

type Compare[T any] interface {
Compare(x, y T) int
}

type CompareConstraints[T any] {
type int, int8, …, float64, string, Compare[T]
}

func Min[T CompareConstraints]Min(x, y T) bool {
switch T {
case int:
…
…
case Compare[T]:
return x.Compare(y) < 0
}
}

понедельник, 24 августа 2020 г. в 06:40:52 UTC+3, Ian Lance Taylor: 

> On Sun, Aug 23, 2020 at 3:00 PM Juliusz Chroboczek  wrote:
> >
> > > We’re going to permit type switches on type parameters that have type
> > > lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> > > clarify code like “switch v := x.(type)”.
> >
> > Could you please give an example of the proposed syntax?
>
> func F[T constraints.Integer]() {
> switch T {
> case int:
> case int8:
> }
> }
>
> 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/4e9391f0-f688-4189-8822-39fc8e217b70n%40googlegroups.com.

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

[Ian Lance Taylor]

On Sun, Aug 23, 2020 at 3:00 PM Juliusz Chroboczek  wrote:
>
> > We’re going to permit type switches on type parameters that have type
> > lists, without the “.(type)” syntax.  The “(.type)” syntax exists to
> > clarify code like “switch v := x.(type)”.
>
> Could you please give an example of the proposed syntax?

func F[T constraints.Integer]() {
switch T {
case int:
case int8:
}
}

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/CAOyqgcU0yWcRd4FwfUnshwLVeZBR7DN1ZBe0rzLBaSRg4UVJpQ%40mail.gmail.com.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Juliusz Chroboczek]

> We’re going to permit type switches on type parameters that have type
> lists, without the “.(type)” syntax.  The “(.type)” syntax exists to
> clarify code like “switch v := x.(type)”.

Could you please give an example of the proposed syntax?

-- 
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/87sgcdowez.fsf%40pirx.irif.fr.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[wilk]

On 21-08-2020, Russ Cox wrote:

> A few other people have raised concerns about not seeing the word interface
> and therefore not realizing "any" is an interface type and potentially
> getting confused. This is also a good consideration, but we already have
> many interface types that don't use the word interface, most notably the
> predefined type error, but also io.Reader, http.ResponseWriter, and so on.
> People learn early on that not all interface types say interface in the
> name. I don't expect that "any" will not be any harder to learn than the
> others.

Why not `anyer` then ?

-- 
Wilk

-- 
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/rhqca3%24e37%241%40ciao.gmane.io.

[go-nuts] Re: [ generics] Moving forward with the generics design draft

[Chris Hines]

I believe these are fantastic choices.

I have given two presentations to Go meetups about the draft generics 
design in the last month. The second time was after the square bracket idea 
was added to the prototype and someone suggested the other parts adopted in 
item #1. In that second presentation I used the []'s syntax while walking 
through some examples and found it really helped the readability. In 
addition I was an instant fan of the [T any] syntax when it was suggested 
and I am happy to see that adopted. The rest of the tweaks are welcome as 
well, especially the addition of type switches on type parameters. I look 
forward to trying that out because I believe it plugs a hole in the design 
I had felt in my earlier experiments.

Well done and thanks to everyone who has helped provide feedback leading to 
these improvements.

Chris

On Thursday, August 20, 2020 at 8:28:23 PM UTC-4 Ian Lance Taylor wrote:

> After many discussions and reading many comments, we plan to move
> forward with some changes and clarifications to the generics design
> draft.
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary parameter list. To avoid the ambiguity with
> array declarations, we will require that all type parameters provide a
> constraint. This has the advantage of giving type parameter lists the
> exact same syntax as ordinary parameter lists (other than using square
> brackets). To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.
>
> The result is declarations that look like this:
>
> type Vector[T any] []T
> func Print[T any](s []T) { … }
> func Index[T comparable](s []T, e T) { … }
>
> We feel that the cost of the new predeclared identifier “any” is
> outweighed by the simplification achieved by making all parameter
> lists syntactically the same: as each regular parameter always has a
> type, each type parameter always has a constraint (its meta-type).
>
> Changing “[type T]” to “[T any]” seems about equally readable and
> saves one character. We’ll be able to streamline a lot of existing
> code in the standard library and elsewhere by replacing “interface{}”
> with “any”.
>
> 2.
>
> We’re going to simplify the rule for type list satisfaction. The type
> argument will satisfy the constraint if the type argument is identical
> to any type in the type list, or if the underlying type of the type
> argument is identical to any type in the type list. What we are
> removing here is any use of the underlying types of the types in the
> type list. This tweaked rule means that the type list can decide
> whether to accept an exact defined type, other than a predeclared
> type, or whether to accept any type with a matching underlying type.
>
> This is a subtle change that we don’t expect to affect any existing
> experimental code.
>
> We think that this definition might work if we permit interface types
> with type lists to be used outside of type constraints. Such
> interfaces would effectively act like sum types. That is not part of
> this design draft, but it’s an obvious thing to consider for the
> future.
>
> Note that a type list can mention type parameters (that is, other type
> parameters in the same type parameter list). These will be checked by
> first replacing the type parameter(s) with the corresponding type
> argument(s), and then using the rule described above.
>
> 3.
>
> We’re going to clarify that when considering the operations permitted
> for a value whose type is a type parameter, we will ignore the methods
> of any types in the type list. The general rule is that the generic
> function can use any operation permitted by every type in the type
> list. However, this will only apply to operators and predeclared
> functions (such as "len" and "cap"). It won’t apply to methods, for
> the case where the type list includes a list of types that all define
> some method. Any methods must be listed separately in the interface
> type, not inherited from the type list.
>
> This rule seems generally clear, and avoids some complex reasoning
> involving type lists that include structs with embedded type
> parameters.
>
> 4.
>
> We’re going to permit type switches on type parameters that have type
> lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> clarify code like “switch v := x.(type)”. A type switch on a type
> parameter won’t be able to use the “:=” syntax anyhow, so there is no
> reason to require “.(type)”. In a type switch on a type parameter
> with a type list, every case listed must be a type that appears in the
> type list (“default” is also permitted, of course). A case will be
> chosen if it is the type matched by the type argument, although as
> discussed above it may not be the