subject:"\[go\-nuts\] \[ generics\] Moving forward with the generics design draft"

On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner
 wrote:
>
> On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor  wrote:
>>
>> Yes, there are various such possibilities.
>>
>> What jimmy frasche said above is correct: nothing changes in the case
>> of a type switch of a type parameter.  The code now knows the type
>> list element that the type argument matched, but it can't do anything
>> that it couldn't do anyhow.
>
>
> I think there are two reasonable things that it could be allowed to do in the 
> case, that aren't allowed outside:
> 1. Convert to the matched type. We have a guarantee that the matched type is 
> either identical or has the same underlying type, both of which would allow a 
> conversion in the language as-is. I feel allowing this conversion would be 
> sufficiently useful (e.g. passing things to `strconv.Itoa` or functions from 
> `math` can be very useful).
> 2. If the type is not a predeclared type, we could even take this a step 
> further, as the types must be identical - so we might allow treating them as 
> such. This feels natural when viewed from the "type lists are essentially sum 
> types" POV. However, it would treat predeclared types more special than other 
> declared types and so it may be too elaborate to put into the spec. It would 
> also allow what rog suggest - but only in certain corner cases, which feels 
> weird.
>
> The more I think about it, the less I understand the intention behind the 
> type-switch construct introduced. I tend to agree that 1. at least should be 
> possible to make it useful. But even then, it seems like kind of a big change 
> for relatively limited use. What was the motivation behind that change? Is 
> there discussion somewhere, of interesting use-cases this enables?

Given a type parameter, there are two interesting pieces of
information.  One is what the actual type argument is; we can already
determine that by writing code like "var x T; switch
(interface{})(x).(type) { ... }".  The other is which type in the type
list was matched by the type argument.  The latter is the purpose of
the type switch suggested here.  Without something like that type
switch, there is no straightforward way for a generic function to
determine which type in a type list is matched by a type argument.

See also 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#identifying-the-matched-predeclared-type
.

I'm not at all wedded to this.  We can continue to omit it.  It just
seems like adding a capability that does not otherwise exist.

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/CAOyqgcWt25q-oboPW%3Dky4gr9GDyrTDewO8NiLjr%2Bb1MrSXMeUg%40mail.gmail.com.

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

On Fri, 21 Aug 2020 at 23:12, jimmy frasche  wrote:

> I don't want a generic min unless it looks like this:
>
> func Min[T constraints.Ordered](a, b T) T {
>   switch T {
>   case float32:
> return T(math.Min(float32(a), float32(b)))
>   case float64:
> return T(math.Min(float64(a), float64(b)))
>   }
>   if a < b {
> return a
>   }
>   return b
> }
>

I'd really like to be able to write that as:

func Min[T constraints.Ordered](a, b T) T {
  switch T {
  case float32:
return math.Min(float64(a), float64(b))
  case float64:
return math.Min(a, b)
  }
  if a < b {
return a
  }
  return b
}

But then there is the difficulty that the original T is no longer the same
as the T inside the type switch.
So this code would print false not true, which would be... somewhat
unexpected: https://go2goplay.golang.org/p/d0cJBfYObAY

Perhaps the type switch* should *allow declaring a new name for the
switched type, making it clear that a new type was being declared inside
the switch.

Something like:

switch T1 := T {
}

but the ":=" operator doesn't seem quite right there, and that still
doesn't solve the original problem, because T1 is still incompatible with
all the argument values. I guess that one could allow conversion or
assignment compatibility between types involving T and T1, but that might
complicate the spec too much.


On Fri, 21 Aug 2020 at 23:12, jimmy frasche  wrote:

> I don't want a generic min unless it looks like this:
>
> func Min[T constraints.Ordered](a, b T) T {
>   switch T {
>   case float32:
> return T(math.Min(float32(a), float32(b)))
>   case float64:
> return T(math.Min(float64(a), float64(b)))
>   }
>   if a < b {
> return a
>   }
>   return b
> }
>
> On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner
>  wrote:
> >
> > On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor 
> wrote:
> >>
> >> Yes, there are various such possibilities.
> >>
> >> What jimmy frasche said above is correct: nothing changes in the case
> >> of a type switch of a type parameter.  The code now knows the type
> >> list element that the type argument matched, but it can't do anything
> >> that it couldn't do anyhow.
> >
> >
> > I think there are two reasonable things that it could be allowed to do
> in the case, that aren't allowed outside:
> > 1. Convert to the matched type. We have a guarantee that the matched
> type is either identical or has the same underlying type, both of which
> would allow a conversion in the language as-is. I feel allowing this
> conversion would be sufficiently useful (e.g. passing things to
> `strconv.Itoa` or functions from `math` can be very useful).
> > 2. If the type is not a predeclared type, we could even take this a step
> further, as the types must be identical - so we might allow treating them
> as such. This feels natural when viewed from the "type lists are
> essentially sum types" POV. However, it would treat predeclared types more
> special than other declared types and so it may be too elaborate to put
> into the spec. It would also allow what rog suggest - but only in certain
> corner cases, which feels weird.
> >
> > The more I think about it, the less I understand the intention behind
> the type-switch construct introduced. I tend to agree that 1. at least
> should be possible to make it useful. But even then, it seems like kind of
> a big change for relatively limited use. What was the motivation behind
> that change? Is there discussion somewhere, of interesting use-cases this
> enables?
> >
> >
> >>
> >>
> >> Ian
> >>
> >> On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner
> >>  wrote:
> >> >
> >> > also, of course, you could still use operators with them, while now
> also knowing the exact semantics of those operators (e.g. in regards to
> overflow), which might also be useful.
> >> >
> >> > On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Aug 21, 2020 at 11:30 PM roger peppe 
> wrote:
> >> >>>
> >> >>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche <
> soapboxcic...@gmail.com> wrote:
> >> 
> >>  I'd assume that would fail to compile as you're returning a []T
> not a []int
> >> >>>
> >> >>>
> >> >>> If that's the case, then I'm not sure that such a type switch would
> be very useful. It would tell you what type the values are, but you can't
> do anything with them because all the values would still be of the original
> type.
> >> >>
> >> >>
> >> >> You can reasonably convert them to their underlying type and *then*
> use them as such.
> >> >> That would make it useful while not allowing what you posit.
> >> >>
> >> >>> I had assumed that the intention was that within the arm of the
> type switch, the switched type would take on the specified type.
> >> >>> That would allow (for example) specialising to use underlying
> machine operations on []T when T is a known type such as byte.
> >> >>
> >> >>
> >> >> It would, however, prevent you from calling methods on the t

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

On Fri, 21 Aug 2020 at 23:03, Axel Wagner 
wrote:

> On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor  wrote:
>
>> Yes, there are various such possibilities.
>>
>> What jimmy frasche said above is correct: nothing changes in the case
>> of a type switch of a type parameter.  The code now knows the type
>> list element that the type argument matched, but it can't do anything
>> that it couldn't do anyhow.
>>
>
> I think there are two reasonable things that it could be allowed to do in
> the case, that aren't allowed outside:
> 1. Convert to the matched type. We have a guarantee that the matched type
> is either identical or has the same underlying type, both of which would
> allow a conversion in the language as-is. I feel allowing this conversion
> would be sufficiently useful (e.g. passing things to `strconv.Itoa` or
> functions from `math` can be very useful).
>

Yes. Without this, I can't see that the type switch is useful for anything
at all other than unsafe operations.

2. If the type is not a predeclared type, we could even take this a step
> further, as the types must be identical - so we might allow treating them
> as such.
>
This feels natural when viewed from the "type lists are essentially sum
> types" POV. However, it would treat predeclared types more special than
> other declared types and so it may be too elaborate to put into the spec.
> It would also allow what rog suggest - but only in certain corner cases,
> which feels weird.
>
> The more I think about it, the less I understand the intention behind the
> type-switch construct introduced. I tend to agree that 1. at least should
> be possible to make it useful. But even then, it seems like kind of a big
> change for relatively limited use. What was the motivation behind that
> change? Is there discussion somewhere, of interesting use-cases this
> enables?
>

As one motivating example, imagine that we had some highly optimized
machine code that sums a slice of 32 bit numbers, but we want to provide a
generic version: https://go2goplay.golang.org/p/0YvkOcc-eBs

I suspect that kind of scenario is one significant use case for using a
type switch in a generic function, and I don't think that the type switch
proposed is sufficient for that.

-- 
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/CAJhgacjn8dOOXU1%2BYZSM7nLDR4fqoCRHTJx3JRy20nN7fb44UA%40mail.gmail.com.

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

On Fri, 21 Aug 2020 at 22:46, Ian Lance Taylor  wrote:

> Yes, there are various such possibilities.
>
> What jimmy frasche said above is correct: nothing changes in the case
> of a type switch of a type parameter.  The code now knows the type
> list element that the type argument matched, but it can't do anything
> that it couldn't do anyhow.
>

I suspect that this would make the new type switch construct very much less
useful.
For example, it wouldn't be possible to specialize a vector operation to
use machine-specific operations on a vector without using unsafe.

It might be interesting to do a survey of some of the reasons that people
would wish to use a type switch on a type parameter and see if the proposed
construct would be sufficient.

Have you got an example of how it might be used?

  cheers,
rog.



>
> Ian
>
> On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner
>  wrote:
> >
> > also, of course, you could still use operators with them, while now also
> knowing the exact semantics of those operators (e.g. in regards to
> overflow), which might also be useful.
> >
> > On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
> >>
> >>
> >>
> >> On Fri, Aug 21, 2020 at 11:30 PM roger peppe 
> wrote:
> >>>
> >>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche 
> wrote:
> 
>  I'd assume that would fail to compile as you're returning a []T not a
> []int
> >>>
> >>>
> >>> If that's the case, then I'm not sure that such a type switch would be
> very useful. It would tell you what type the values are, but you can't do
> anything with them because all the values would still be of the original
> type.
> >>
> >>
> >> You can reasonably convert them to their underlying type and *then* use
> them as such.
> >> That would make it useful while not allowing what you posit.
> >>
> >>> I had assumed that the intention was that within the arm of the type
> switch, the switched type would take on the specified type.
> >>> That would allow (for example) specialising to use underlying machine
> operations on []T when T is a known type such as byte.
> >>
> >>
> >> It would, however, prevent you from calling methods on the type or pass
> it to a function taking an interface compatible with the constraint.
> >> Also, I shudder to even imagine how this could be put into a spec.
> >>
> >>>
> >>>
> >>>
>  On Fri, Aug 21, 2020 at 2:07 PM roger peppe 
> wrote:
>  >
>  >
>  > On Fri, 21 Aug 2020 at 01:28, 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 exp

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

2020-08-21 Thread jimmy frasche

I don't want a generic min unless it looks like this:

func Min[T constraints.Ordered](a, b T) T {
  switch T {
  case float32:
return T(math.Min(float32(a), float32(b)))
  case float64:
return T(math.Min(float64(a), float64(b)))
  }
  if a < b {
return a
  }
  return b
}

On Fri, Aug 21, 2020 at 3:03 PM Axel Wagner
 wrote:
>
> On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor  wrote:
>>
>> Yes, there are various such possibilities.
>>
>> What jimmy frasche said above is correct: nothing changes in the case
>> of a type switch of a type parameter.  The code now knows the type
>> list element that the type argument matched, but it can't do anything
>> that it couldn't do anyhow.
>
>
> I think there are two reasonable things that it could be allowed to do in the 
> case, that aren't allowed outside:
> 1. Convert to the matched type. We have a guarantee that the matched type is 
> either identical or has the same underlying type, both of which would allow a 
> conversion in the language as-is. I feel allowing this conversion would be 
> sufficiently useful (e.g. passing things to `strconv.Itoa` or functions from 
> `math` can be very useful).
> 2. If the type is not a predeclared type, we could even take this a step 
> further, as the types must be identical - so we might allow treating them as 
> such. This feels natural when viewed from the "type lists are essentially sum 
> types" POV. However, it would treat predeclared types more special than other 
> declared types and so it may be too elaborate to put into the spec. It would 
> also allow what rog suggest - but only in certain corner cases, which feels 
> weird.
>
> The more I think about it, the less I understand the intention behind the 
> type-switch construct introduced. I tend to agree that 1. at least should be 
> possible to make it useful. But even then, it seems like kind of a big change 
> for relatively limited use. What was the motivation behind that change? Is 
> there discussion somewhere, of interesting use-cases this enables?
>
>
>>
>>
>> Ian
>>
>> On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner
>>  wrote:
>> >
>> > also, of course, you could still use operators with them, while now also 
>> > knowing the exact semantics of those operators (e.g. in regards to 
>> > overflow), which might also be useful.
>> >
>> > On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner 
>> >  wrote:
>> >>
>> >>
>> >>
>> >> On Fri, Aug 21, 2020 at 11:30 PM roger peppe  wrote:
>> >>>
>> >>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche  
>> >>> wrote:
>> 
>>  I'd assume that would fail to compile as you're returning a []T not a 
>>  []int
>> >>>
>> >>>
>> >>> If that's the case, then I'm not sure that such a type switch would be 
>> >>> very useful. It would tell you what type the values are, but you can't 
>> >>> do anything with them because all the values would still be of the 
>> >>> original type.
>> >>
>> >>
>> >> You can reasonably convert them to their underlying type and *then* use 
>> >> them as such.
>> >> That would make it useful while not allowing what you posit.
>> >>
>> >>> I had assumed that the intention was that within the arm of the type 
>> >>> switch, the switched type would take on the specified type.
>> >>> That would allow (for example) specialising to use underlying machine 
>> >>> operations on []T when T is a known type such as byte.
>> >>
>> >>
>> >> It would, however, prevent you from calling methods on the type or pass 
>> >> it to a function taking an interface compatible with the constraint.
>> >> Also, I shudder to even imagine how this could be put into a spec.
>> >>
>> >>>
>> >>>
>> >>>
>>  On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
>>  >
>>  >
>>  > On Fri, 21 Aug 2020 at 01:28, 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

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

On Fri, Aug 21, 2020 at 11:46 PM Ian Lance Taylor  wrote:

> Yes, there are various such possibilities.
>
> What jimmy frasche said above is correct: nothing changes in the case
> of a type switch of a type parameter.  The code now knows the type
> list element that the type argument matched, but it can't do anything
> that it couldn't do anyhow.
>

I think there are two reasonable things that it could be allowed to do in
the case, that aren't allowed outside:
1. Convert to the matched type. We have a guarantee that the matched type
is either identical or has the same underlying type, both of which would
allow a conversion in the language as-is. I feel allowing this conversion
would be sufficiently useful (e.g. passing things to `strconv.Itoa` or
functions from `math` can be very useful).
2. If the type is not a predeclared type, we could even take this a step
further, as the types must be identical - so we might allow treating them
as such. This feels natural when viewed from the "type lists are
essentially sum types" POV. However, it would treat predeclared types more
special than other declared types and so it may be too elaborate to put
into the spec. It would also allow what rog suggest - but only in certain
corner cases, which feels weird.

The more I think about it, the less I understand the intention behind the
type-switch construct introduced. I tend to agree that 1. at least should
be possible to make it useful. But even then, it seems like kind of a big
change for relatively limited use. What was the motivation behind that
change? Is there discussion somewhere, of interesting use-cases this
enables?



>
> Ian
>
> On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner
>  wrote:
> >
> > also, of course, you could still use operators with them, while now also
> knowing the exact semantics of those operators (e.g. in regards to
> overflow), which might also be useful.
> >
> > On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
> >>
> >>
> >>
> >> On Fri, Aug 21, 2020 at 11:30 PM roger peppe 
> wrote:
> >>>
> >>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche 
> wrote:
> 
>  I'd assume that would fail to compile as you're returning a []T not a
> []int
> >>>
> >>>
> >>> If that's the case, then I'm not sure that such a type switch would be
> very useful. It would tell you what type the values are, but you can't do
> anything with them because all the values would still be of the original
> type.
> >>
> >>
> >> You can reasonably convert them to their underlying type and *then* use
> them as such.
> >> That would make it useful while not allowing what you posit.
> >>
> >>> I had assumed that the intention was that within the arm of the type
> switch, the switched type would take on the specified type.
> >>> That would allow (for example) specialising to use underlying machine
> operations on []T when T is a known type such as byte.
> >>
> >>
> >> It would, however, prevent you from calling methods on the type or pass
> it to a function taking an interface compatible with the constraint.
> >> Also, I shudder to even imagine how this could be put into a spec.
> >>
> >>>
> >>>
> >>>
>  On Fri, Aug 21, 2020 at 2:07 PM roger peppe 
> wrote:
>  >
>  >
>  > On Fri, 21 Aug 2020 at 01:28, 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

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

2020-08-21 Thread Bakul Shah

On Aug 21, 2020, at 2:07 PM, roger peppe  wrote:
> 
> Here's one interesting implication of this: it allows us to do type 
> conversions that were not previously possible.
> 
> For example, if we have "type I int", we can use a type switch to convert 
> some type []I to type []int:
> https://go2goplay.golang.org/p/-860Zlz7-cn
> 
> func F[type T intlike](ts []T) []int {
>switch T {
>case int:
>return ts
>}
>return nil
> }

IMHO this should work. This makes sense to me because I think
of generics as merely constrained compile time macros :-) The
switch can removed at compile time by the compiler. [Note that
in this regard "intlike" is *different* from sum types, which are
a runtime concept that Go doesn't have (except for interface{}).]

-- 
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/74732864-340B-4F23-A578-7E6C65DE256D%40iitbombay.org.

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

Yes, there are various such possibilities.

What jimmy frasche said above is correct: nothing changes in the case
of a type switch of a type parameter.  The code now knows the type
list element that the type argument matched, but it can't do anything
that it couldn't do anyhow.

Ian

On Fri, Aug 21, 2020 at 2:43 PM Axel Wagner
 wrote:
>
> also, of course, you could still use operators with them, while now also 
> knowing the exact semantics of those operators (e.g. in regards to overflow), 
> which might also be useful.
>
> On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner  
> wrote:
>>
>>
>>
>> On Fri, Aug 21, 2020 at 11:30 PM roger peppe  wrote:
>>>
>>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche  wrote:

 I'd assume that would fail to compile as you're returning a []T not a []int
>>>
>>>
>>> If that's the case, then I'm not sure that such a type switch would be very 
>>> useful. It would tell you what type the values are, but you can't do 
>>> anything with them because all the values would still be of the original 
>>> type.
>>
>>
>> You can reasonably convert them to their underlying type and *then* use them 
>> as such.
>> That would make it useful while not allowing what you posit.
>>
>>> I had assumed that the intention was that within the arm of the type 
>>> switch, the switched type would take on the specified type.
>>> That would allow (for example) specialising to use underlying machine 
>>> operations on []T when T is a known type such as byte.
>>
>>
>> It would, however, prevent you from calling methods on the type or pass it 
>> to a function taking an interface compatible with the constraint.
>> Also, I shudder to even imagine how this could be put into a spec.
>>
>>>
>>>
>>>
 On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
 >
 >
 > On Fri, 21 Aug 2020 at 01:28, 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 th

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

also, of course, you could still use operators with them, while now also
knowing the exact semantics of those operators (e.g. in regards to
overflow), which might also be useful.

On Fri, Aug 21, 2020 at 11:42 PM Axel Wagner 
wrote:

>
>
> On Fri, Aug 21, 2020 at 11:30 PM roger peppe  wrote:
>
>> On Fri, 21 Aug 2020 at 22:10, jimmy frasche 
>> wrote:
>>
>>> I'd assume that would fail to compile as you're returning a []T not a
>>> []int
>>>
>>
>> If that's the case, then I'm not sure that such a type switch would be
>> very useful. It would tell you what type the values are, but you can't do
>> anything with them because all the values would still be of the original
>> type.
>>
>
> You can reasonably convert them to their underlying type and *then* use
> them as such.
> That would make it useful while not allowing what you posit.
>
> I had assumed that the intention was that within the arm of the type
>> switch, the switched type would take on the specified type.
>> That would allow (for example) specialising to use underlying machine
>> operations on []T when T is a known type such as byte.
>>
>
> It would, however, prevent you from calling methods on the type or pass it
> to a function taking an interface compatible with the constraint.
> Also, I shudder to even imagine how this could be put into a spec.
>
>
>>
>>
>> On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
>>> >
>>> >
>>> > On Fri, 21 Aug 2020 at 01:28, 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

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

On Fri, Aug 21, 2020 at 11:30 PM roger peppe  wrote:

> On Fri, 21 Aug 2020 at 22:10, jimmy frasche 
> wrote:
>
>> I'd assume that would fail to compile as you're returning a []T not a
>> []int
>>
>
> If that's the case, then I'm not sure that such a type switch would be
> very useful. It would tell you what type the values are, but you can't do
> anything with them because all the values would still be of the original
> type.
>

You can reasonably convert them to their underlying type and *then* use
them as such.
That would make it useful while not allowing what you posit.

I had assumed that the intention was that within the arm of the type
> switch, the switched type would take on the specified type.
> That would allow (for example) specialising to use underlying machine
> operations on []T when T is a known type such as byte.
>

It would, however, prevent you from calling methods on the type or pass it
to a function taking an interface compatible with the constraint.
Also, I shudder to even imagine how this could be put into a spec.


>
>
> On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
>> >
>> >
>> > On Fri, 21 Aug 2020 at 01:28, 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 p

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

On Fri, 21 Aug 2020 at 22:10, jimmy frasche  wrote:

> I'd assume that would fail to compile as you're returning a []T not a []int
>

If that's the case, then I'm not sure that such a type switch would be very
useful. It would tell you what type the values are, but you can't do
anything with them because all the values would still be of the original
type.

I had assumed that the intention was that within the arm of the type
switch, the switched type would take on the specified type.
That would allow (for example) specialising to use underlying machine
operations on []T when T is a known type such as byte.


On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
> >
> >
> > On Fri, 21 Aug 2020 at 01:28, 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 m

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

2020-08-21 Thread jimmy frasche

I'd assume that would fail to compile as you're returning a []T not a []int

On Fri, Aug 21, 2020 at 2:07 PM roger peppe  wrote:
>
>
> On Fri, 21 Aug 2020 at 01:28, 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.
>
>
> Here's one interesting implication of this: it allows us to do type 
> conversions that were not previously possible.
>
> For example, if we have "type I int", we can use a type switch to convert 
> some type []I to type []int:
> https://go2goplay.golang.org/p/-860Zlz7-cn
>
> func F[type T intlike](ts []T) []int {
> switch T {
> case int:
> return ts
> }
> return nil
> }
>
> It seems to me that this kind of thing will allow us to perform a similar 
> conversion (convert some part of the type to its underlying type) on any ty

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

On Fri, 21 Aug 2020 at 01:28, 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.


Here's one interesting implication of this: it allows us to do type
conversions that were not previously possible.

For example, if we have "type I int", we can use a type switch to convert
some type []I to type []int:
https://go2goplay.golang.org/p/-860Zlz7-cn

func F[type T intlike](ts []T) []int {
switch T {
case int:
return ts
}
return nil
}

It seems to me that this kind of thing will allow us to perform a similar
conversion (convert some part of the type to its underlying type) on any
type.

In the early days of Go, the spec allowed this kind of conversion
 as a normal type conversion. I
wonder if it might be reasonable to revert to those more relaxed semantics.
I think they're potentially useful, for

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

2020-08-21 Thread Russ Cox

Hi all,

A few people have raised concerns about "encouraging" use of any instead of
interface{}, on the grounds that it is not idiomatic Go. I just wanted to
acknowledge that yes, it's not idiomatic Go today, but that's true of
essentially every language change. Thinking about future usage is a good
consideration, but we define idiomatic by convention, and that convention
is heavily influenced by what is and is not in the language. It is OK for
the convention to shift, and here it almost certainly would.

Many years ago, there was no rune type in Go. We used int instead, as in:

runes := []int("hello")

It would certainly not have been idiomatic at the time to instead define

type rune = int

and then write code like:

runes := []rune("hello")

The argument against doing this would be that everyone expects to see []int
instead, and that introducing your own custom definition here for a
standard language concept adds to the conceptual burden for readers by
making your code look different from everyone else's, forcing readers to
search out the definition of "rune" to understand the code. (It was equally
non-idiomatic to define "type error = os.Error" before we had the
predefined error type.)

The same argument that applied back then to a custom rune = int or error =
os.Error alias applies today to a custom any = interface{} alias: it's not
a good thing to make your code gratuitously different from others' code.

But just as "type rune = int" being non-idiomatic did not
preclude introducing a *standard* predefined rune type alias, the fact that
"type any = interface{}" is non-idiomatic today does not preclude
introducing a standard predefined any type alias. It becomes idiomatic by
making it part of the language. Then everyone can use it, and no one's code
is gratuitously different.

It's also true that older Go code using interface{} will look different
from newer Go code using "any". But that is true of every language change.
New code that omits semicolons looks different from old code that doesn't.
New code that writes 0o777 looks different from old code that writes 0777.
And so on, for every change we make. This is fundamental to languages
evolving: new code and old code look different. (Part of minimizing
the need to code switch is providing tools to help update old code to look
new; we've done that repeatedly in the past and would undoubtedly do that
here as well.)

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.

In any (ha!) event, it's probably more important to focus on the larger
semantics of generics than this specific color, attractive though it may be.

Best,
Russ

--
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/CAA8EjDQvv95bweUeWK6jDA2aQ2F1uuZh5MCRZuTHJ%2BBHMCj2-Q%40mail.gmail.com.

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

2020-08-21 Thread Russ Cox

On Fri, Aug 21, 2020 at 1:30 PM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> My one concern with making it an alias is error messages.
> If the source code says "any", I think so should the error messages.
> Currently, the compiler forgets aliases too early
> .
>

https://github.com/golang/go/issues/40965, 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/CAA8EjDRPrpZhx0bJHUfqVeU%2BfJjfKmCGSMZx87u-aD%2BHUMvBwQ%40mail.gmail.com.

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

2020-08-21 Thread Viktor Kojouharov

I like all points in the draft change.

My 2 cents around the any alias would be that it shouldn't be a problem. I 
don't think people are suddently going to start overusing it, since using 
vaues of type `interface{}` is extremely tedious in Go, and that won't 
magically change if the type is shorter by a few characters.

One thing that might be of concern regarding using type lists in interfaces 
is that, if that is allowed outside of generics, then it should be decided 
beforehand whether a type switch over such values is exhaustive or not. I 
don't think it will be a breaking change if it is exhaustive for such 
interfaces, but if it isn't, then changing it later would be. For the 
record, I think it should b exhaustive.

On Friday, August 21, 2020 at 8:15:46 PM UTC+2 bbse...@gmail.com wrote:

> On Fri, Aug 21, 2020 at 11:01 AM 'Carla Pfaff' via golang-nuts
>  wrote:
> >
> > On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote:
> >>
> >> All constraints except "any" specify a constraint for the type. A
> >> Stringer constraint will ensure that the type has String() string
> >> method. "any" is a lack of constraint.
> >
> >
> > The empty interface / any is a constraint that ensures that the type has 
> at least 0 methods and all of these 0 methods must match the 0 methods of 
> the interface. An empty purse is still a purse, an empty constraint is 
> still a constraint.
> >
> >>
> >> My problem is the attractiveness of "any" as a return type.
> >
> >
> > I don't see why anybody would find it attractive as a return type. 
> People don't use the empty interface because they like it so much, but 
> because Go doesn't have parametric polymorphism / "generics" yet. There are 
> many programming languages that have a named top type and it is rarely 
> abused. Programmers want to write type safe code if they can.
>
> I disagree. Especially people coming from other languages with a
> strong emphasis on DRY tend to overuse interface{}, many times
> incorrectly, and generics will not fix that. "any" will make it more
> attractive, because it no longer looks like an interface. I agree that
> this is a hypothetical problem at this point without any actual
> complaints from developers. But defining an alias "any" is easy if you
> need it. Providing one predefined is endorsing its use.
>
> >
> > --
> > 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/8e5b46ba-7a3e-4d55-ac97-1e70d06e622dn%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/4245d27a-fcc6-438d-8b6d-d1ba44eb18c3n%40googlegroups.com.

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

2020-08-21 Thread burak serdar

On Fri, Aug 21, 2020 at 11:01 AM 'Carla Pfaff' via golang-nuts
 wrote:
>
> On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote:
>>
>> All constraints except "any" specify a constraint for the type. A
>> Stringer constraint will ensure that the type has String() string
>> method. "any" is a lack of constraint.
>
>
> The empty interface / any is a constraint that ensures that the type has at 
> least 0 methods and all of these 0 methods must match the 0 methods of the 
> interface. An empty purse is still a purse, an empty constraint is still a 
> constraint.
>
>>
>> My problem is the attractiveness of "any" as a return type.
>
>
> I don't see why anybody would find it attractive as a return type. People 
> don't use the empty interface because they like it so much, but because Go 
> doesn't have parametric polymorphism / "generics" yet. There are many 
> programming languages that have a named top type and it is rarely abused. 
> Programmers want to write type safe code if they can.

I disagree. Especially people coming from other languages with a
strong emphasis on DRY tend to overuse interface{}, many times
incorrectly, and generics will not fix that. "any" will make it more
attractive, because it no longer looks like an interface. I agree that
this is a hypothetical problem at this point without any actual
complaints from developers. But defining an alias "any" is easy if you
need it. Providing one predefined is endorsing its use.

>
> --
> 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/8e5b46ba-7a3e-4d55-ac97-1e70d06e622dn%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/CAMV2RqpYM8n%2BC-dDot2D1fJXDMWgmwXDy84u8VPWiV92oVWKOA%40mail.gmail.com.

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

2020-08-21 Thread Denis Cheremisov

BTW, I am really glad your proposal is accepted, now the whole thing feels 
polished and IMO it is time to start building an implementation.

пятница, 21 августа 2020 г. в 20:02:17 UTC+3, Carla Pfaff: 

> On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote:
>
>> All constraints except "any" specify a constraint for the type. A 
>> Stringer constraint will ensure that the type has String() string 
>> method. "any" is a lack of constraint. 
>
>
> The empty interface / any is a constraint that ensures that the type has 
> at least 0 methods and all of these 0 methods must match the 0 methods of 
> the interface. An empty purse is still a purse, an empty constraint is 
> still a constraint.
>  
>
>> My problem is the attractiveness of "any" as a return type. 
>>
>
> I don't see why anybody would find it attractive as a return type. People 
> don't use the empty interface because they like it so much, but because Go 
> doesn't have parametric polymorphism / "generics" yet. There are many 
> programming languages that have a named top type and it is rarely abused. 
> Programmers want to write type safe code if they can.
>

-- 
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/137a5799-2bb7-402c-a972-e7da0789c890n%40googlegroups.com.

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

On Fri, 21 Aug 2020 at 18:30, Axel Wagner 
wrote:

> My one concern with making it an alias is error messages.
> If the source code says "any", I think so should the error messages.
> Currently, the compiler forgets aliases too early
> .
>

I agree that's a concern, but I think that should be a reason to fix error
messages when aliases are used, not to use a named type.


> On Fri, Aug 21, 2020 at 7:08 PM roger peppe  wrote:
>
>>
>>
>> On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor  wrote:
>>
>>> On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
 Just to clarify, the intent is to make the declaration in the spec
 `type any = interface{}`, not `type any interface{}`, correct? The latter
 would be more analogous to `error`. Either has certain advantages and
 disadvantages, I'm not sure which I prefer, but I just want to make sure I
 understand the plan :)

>>>
>>> I've been thinking of a type alias rather than a defined type, but I'm
>>> not sure which is best.  It would be interesting to hear whether anybody
>>> has a clear preference, and why.
>>>
>>
>> My vote is for a type alias. Using a named type doesn't make any
>> difference for type parameter constraints, and I'd prefer it if
>> "[]interface{}" and "[]any" (or other types involving interface{}) weren't
>> incompatible types. "interface{}" is currently a nice universally
>> understood type - I don't think it's worth splitting it into two distinct
>> types.
>>
>>   cheers,
>> rog.
>>
>>
>>
>>
>>> 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/CAOyqgcUFU_Lz0c%3D-6V6N9X2Ku2Hx-9%2BDeHequ0oLX9Soyo_3GQ%40mail.gmail.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/CAJhgacgo9Ww3dMkpLxw-raAq97mMD4t6ZWsW0yX%3DFqDV%3DEBRHA%40mail.gmail.com.

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

My one concern with making it an alias is error messages.
If the source code says "any", I think so should the error messages.
Currently, the compiler forgets aliases too early
.

On Fri, Aug 21, 2020 at 7:08 PM roger peppe  wrote:

>
>
> On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor  wrote:
>
>> On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> Just to clarify, the intent is to make the declaration in the spec `type
>>> any = interface{}`, not `type any interface{}`, correct? The latter would
>>> be more analogous to `error`. Either has certain advantages and
>>> disadvantages, I'm not sure which I prefer, but I just want to make sure I
>>> understand the plan :)
>>>
>>
>> I've been thinking of a type alias rather than a defined type, but I'm
>> not sure which is best.  It would be interesting to hear whether anybody
>> has a clear preference, and why.
>>
>
> My vote is for a type alias. Using a named type doesn't make any
> difference for type parameter constraints, and I'd prefer it if
> "[]interface{}" and "[]any" (or other types involving interface{}) weren't
> incompatible types. "interface{}" is currently a nice universally
> understood type - I don't think it's worth splitting it into two distinct
> types.
>
>   cheers,
> rog.
>
>
>
>
>> 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/CAOyqgcUFU_Lz0c%3D-6V6N9X2Ku2Hx-9%2BDeHequ0oLX9Soyo_3GQ%40mail.gmail.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/CAEkBMfG5vR-xcsNsR%2Bsh18iYe5sFKs2bwqC%3Dqs5xBtFoR1-1Ew%40mail.gmail.com.

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

2020-08-21 Thread Jan Mercl

On Fri, Aug 21, 2020, 19:01 'Carla Pfaff' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

People don't use the empty interface because they like it so much, but
because Go doesn't have parametric polymorphism / "generics" yet.


This argument seems to fail the fmt.Printf and friends reality check.

-- 
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/CAA40n-VdEAh9JmeB4sRJxDpamD%2B1W8SDXvbO0YUjxHMfNDtrWg%40mail.gmail.com.

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

On Fri, 21 Aug 2020 at 15:24, Ian Lance Taylor  wrote:

> On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> Just to clarify, the intent is to make the declaration in the spec `type
>> any = interface{}`, not `type any interface{}`, correct? The latter would
>> be more analogous to `error`. Either has certain advantages and
>> disadvantages, I'm not sure which I prefer, but I just want to make sure I
>> understand the plan :)
>>
>
> I've been thinking of a type alias rather than a defined type, but I'm not
> sure which is best.  It would be interesting to hear whether anybody has a
> clear preference, and why.
>

My vote is for a type alias. Using a named type doesn't make any difference
for type parameter constraints, and I'd prefer it if "[]interface{}" and
"[]any" (or other types involving interface{}) weren't incompatible types.
"interface{}" is currently a nice universally understood type - I don't
think it's worth splitting it into two distinct types.

  cheers,
rog.




> 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/CAOyqgcUFU_Lz0c%3D-6V6N9X2Ku2Hx-9%2BDeHequ0oLX9Soyo_3GQ%40mail.gmail.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/CAJhgacgfGtxA4u3qrB3qpGowFqMBBHCOS%3DcN1NdUmgaiZpZrYw%40mail.gmail.com.

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

2020-08-21 Thread 'Carla Pfaff' via golang-nuts

On Friday, 21 August 2020 at 16:46:22 UTC+2 bbse...@gmail.com wrote:

> All constraints except "any" specify a constraint for the type. A 
> Stringer constraint will ensure that the type has String() string 
> method. "any" is a lack of constraint. 

The empty interface / any is a constraint that ensures that the type has at 
least 0 methods and all of these 0 methods must match the 0 methods of the 
interface. An empty purse is still a purse, an empty constraint is still a 
constraint.

> My problem is the attractiveness of "any" as a return type. 
>

I don't see why anybody would find it attractive as a return type. People 
don't use the empty interface because they like it so much, but because Go 
doesn't have parametric polymorphism / "generics" yet. There are many 
programming languages that have a named top type and it is rarely abused. 
Programmers want to write type safe code if they can.

-- 
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/8e5b46ba-7a3e-4d55-ac97-1e70d06e622dn%40googlegroups.com.

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

2020-08-21 Thread burak serdar

On Fri, Aug 21, 2020 at 7:43 AM 'Carla Pfaff' via golang-nuts
 wrote:
>
> On Friday, 21 August 2020 at 14:57:13 UTC+2 bbse...@gmail.com wrote:
>>
>> interface{}, when used as a constraint, doesn't mean than the value
>> has to be an interface{}, it means the value can be anything.
>> interface{}, when used as a value, doesn't mean that the value can be
>> anything, it means that the value is an interface, and you have to get
>> the value from that interface. Different uses, different identifiers.
>
>
> The same is true for "interface{String() string}" as a constraint and 
> "interface{String() string}" as a type.
> Does that mean that you want to allow the identifier "fmt.Stringer" only for 
> constraints, but not for types?

All constraints except "any" specify a constraint for the type. A
Stringer constraint will ensure that the type has String() string
method. "any" is a lack of constraint. I think the two concepts are
different. My problem is the attractiveness of "any" as a return type.
I can live with it, but I expect to see more questions raised about
functions returning "any" values behaving weird in a nil-check.


>
> --
> 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/4c9a2735-3e22-4568-ac0b-8c6a8b4b8583n%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/CAMV2RqrUdiTFs20uuPLTLf40yz2bHJZRM-ihcH%3DUD7STrzt2Kg%40mail.gmail.com.

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

On Fri, 21 Aug 2020 at 01:28, 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”.
>

This is great. I like the fact that the type parameter list is just a
normally formed parameter list now.
I did quite like the fact that you could see defined types with a grep for
"type", but that's
not always the case anyway with type blocks, so I'll put that feeling aside.

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.
>

This is also a great forward-looking change.


>
> 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.
>

Ditto.


>
> 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

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

On Thu, Aug 20, 2020, 11:22 PM Bakul Shah  wrote:

> On Aug 20, 2020, at 5:27 PM, Ian Lance Taylor  wrote:
>
> > 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.
>
> You seem to be saying a generic function can use operator X only if
> if *every* type in the type list implements it. Thus if I have
>
> type foo interface { int; someSLice }
>
> I can't use + and I can't use len(), right?


Right.  And, to be clear, that is how the current design draft works before
this change.

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

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

On Fri, Aug 21, 2020, 12:37 AM 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Just to clarify, the intent is to make the declaration in the spec `type
> any = interface{}`, not `type any interface{}`, correct? The latter would
> be more analogous to `error`. Either has certain advantages and
> disadvantages, I'm not sure which I prefer, but I just want to make sure I
> understand the plan :)
>

I've been thinking of a type alias rather than a defined type, but I'm not
sure which is best.  It would be interesting to hear whether anybody has a
clear preference, and why.

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/CAOyqgcUFU_Lz0c%3D-6V6N9X2Ku2Hx-9%2BDeHequ0oLX9Soyo_3GQ%40mail.gmail.com.

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

2020-08-21 Thread 'Carla Pfaff' via golang-nuts

On Friday, 21 August 2020 at 14:57:13 UTC+2 bbse...@gmail.com wrote:

> interface{}, when used as a constraint, doesn't mean than the value 
> has to be an interface{}, it means the value can be anything. 
> interface{}, when used as a value, doesn't mean that the value can be 
> anything, it means that the value is an interface, and you have to get 
> the value from that interface. Different uses, different identifiers. 

 
The same is true for "interface{String() string}" as a constraint and 
"interface{String() string}" as a type.
Does that mean that you want to allow the identifier "fmt.Stringer" only 
for constraints, but not for types?

-- 
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/4c9a2735-3e22-4568-ac0b-8c6a8b4b8583n%40googlegroups.com.

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

2020-08-21 Thread burak serdar

On Thu, Aug 20, 2020 at 11:54 PM Kurtis Rader  wrote:
>
> On Thu, Aug 20, 2020 at 10:40 PM burak serdar  wrote:
>>
>> What worries me is code like this:
>>
>> func f() any {
>>int *i
>>   return i
>> }
>>
>> func main() {
>>if f()==nil {
>> ...
>>}
>> }
>>
>> Use of "any" makes it look like f returns an *int and f() is nil, but
>> it is not, because "any" is interface{}.
>>
>> I think "any" as a constraint is useful, like "comparable", but "any"
>> as a type is misleading.
>
>
> Isn't your example just a case of confusing a nil interface with a nil value 
> inside a generic interface? How does requiring writing it as `func f() 
> interface{} {` make the behavior any clearer?

The point I was trying to make is that "any" as a constraint is better
than "interface{}" as a constraint, but "interface{}" as a type is
better than "any" as a type.

interface{}, when used as a constraint, doesn't mean than the value
has to be an interface{}, it means the value can be anything.
interface{}, when used as a value, doesn't mean that the value can be
anything, it means that the value is an interface, and you have to get
the value from that interface. Different uses, different identifiers.

I would be more comfortable if "any" was only a constraint instead of
an alias for interface{}. If your code needs it, you can still define
it. But if it is there, people will use it even if they can do without
it.

That said, I think the generics design draft looks great.

>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank

-- 
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/CAMV2RqrVLzZ-mz9m2_RKVhybiGt2cPU1yKs-VB_d2nO3BO2qJg%40mail.gmail.com.

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

2020-08-21 Thread David Riley

On Aug 21, 2020, at 00:56, Ian Lance Taylor  wrote:
> 
> No, the intent is that you would switch on the type parameter itself,
> not a value.
> 
> func g[T C](v T) T {
>  switch T {
>// the rest is the same
>  }
> }
> 
> Thanks for asking.

Oh, this clarifies my remaining murkiness about the type switches quite nicely. 
Thanks!

- Dave

-- 
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/863C3CE1-E027-42C8-9200-2DEBF8D0B966%40gmail.com.

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