date:20200821

On Fri, Aug 21, 2020, 9:16 PM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Sat, 2020-08-15 at 21:44 -0700, Ian Lance Taylor wrote:
> > On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts
> >  wrote:
> > >
> > > I would like to be able to obtain the original type for an alias
> > > given
> > > a source input. I can see in "go/types" that it's possible to know
> > > whether a named type is an alias by `typ.Obj().IsAlias()`, but I
> > > cannot
> > > see how to obtain the actual original type unless it is an alias
> > > for a
> > > basic type.
> > >
> > > Can someone point me to a way to get this information? From the
> > > source
> > > it looks something like
> > > `typ.Obj().Type().(*types.Named).Obj().Type()`.
> > > Is this correct assuming that the original type is a named type?
> >
> > I haven't tested it but I *think* you can just write
> > typ.Underlying().
> >
> > Ian
>
> Thanks, Ian.
>
> No that doesn't work. For example with type byte, you get back the byte
> name.
>
> https://play.golang.org/p/PPjHBotsIsw


The underlying type of byte is indeed byte.  What are you hoping for?

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/CAOyqgcX6Dwe1-YduJ_kvAGj%2B6N0uVYAiqK0-NJo3-yDukkuWXA%40mail.gmail.com.

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

2020-08-21 Thread 'Dan Kortschak' via golang-nuts

On Sat, 2020-08-15 at 21:44 -0700, Ian Lance Taylor wrote:
> On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts
>  wrote:
> > 
> > I would like to be able to obtain the original type for an alias
> > given
> > a source input. I can see in "go/types" that it's possible to know
> > whether a named type is an alias by `typ.Obj().IsAlias()`, but I
> > cannot
> > see how to obtain the actual original type unless it is an alias
> > for a
> > basic type.
> > 
> > Can someone point me to a way to get this information? From the
> > source
> > it looks something like
> > `typ.Obj().Type().(*types.Named).Obj().Type()`.
> > Is this correct assuming that the original type is a named type?
> 
> I haven't tested it but I *think* you can just write
> typ.Underlying().
> 
> Ian

Thanks, Ian.

No that doesn't work. For example with type byte, you get back the byte
name.

https://play.golang.org/p/PPjHBotsIsw

Dan


-- 
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/d3f6c5b7a76f7ea2db93f34fa87917651dcc7ad5.camel%40kortschak.io.

Re: [go-nuts] Debug http calls made using go http client

2020-08-21 Thread Robert Engels

I would use wire shark to inspect the traffic in more detail. 

> On Aug 21, 2020, at 1:59 PM, krishna...@gmail.com  
> wrote:
> 
> 
> Hello Gophers,
> 
> I am making multiple http calls from my go application to an external 
> vendor's http server using the go standard http client. I've set a 10 second 
> timeout for my context. Everything works fine. 
> 
> However, I get random timeouts in my application due to these HTTP calls. On 
> further investigation, I found that the http calls to the vendor's server 
> take longer than 10 seconds. 
> During this period of timeouts, the vendor says they've not received any HTTP 
> requests. How do I verify that the http requests are made from my app? If the 
> requests are made from my app, how can I figure out what's causing the delay?
> 
> I tried debugging using the HTTP client trace, but couldn't find any 
> actionable information. Any suggestions on how to debug/fix this issue ?
> 
> Thanks
> - Krishna 
> -- 
> 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/2d454dda-6670-48ef-85a2-0a42216dcd29n%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/397154E2-D9E6-4DB4-B3AF-2D4F6A3EF792%40ix.netcom.com.

Re: [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] Unique GO language features

On Fri, Aug 21, 2020 at 10:16 AM joseph.p...@gmail.com
 wrote:
>
> I really like the 'defer' statement and think it would be a useful addition 
> to other programming languages.

I believe that Swift has also added a defer statement, which I assume
was based on the idea in Go.

> The feature where GO performs escape analysis and promotes stack variables to 
> the heap: Did that originate with GO or was it first implemented elsewhere?

That has been implemented in other languages, notably Java.

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/CAOyqgcWqcy01WBwyt4Y9be968nW2kE-90%2BBs0ETYmuSeaXDEsQ%40mail.gmail.com.

[go-nuts] Debug http calls made using go http client

2020-08-21 Thread krishna...@gmail.com

Hello Gophers,

I am making multiple http calls from my go application to an external 
vendor's http server using the go standard http client. I've set a 10 
second timeout for my context. Everything works fine. 

However, I get random timeouts in my application due to these HTTP calls. 
On further investigation, I found that the http calls to the vendor's 
server take longer than 10 seconds. 
During this period of timeouts, the vendor says they've not received any 
HTTP requests. How do I verify that the http requests are made from my app? 
If the requests are made from my app, how can I figure out what's causing 
the delay?

I tried debugging using the HTTP client trace, but couldn't find any 
actionable information. Any suggestions on how to debug/fix this issue ?

Thanks
- Krishna 

-- 
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/2d454dda-6670-48ef-85a2-0a42216dcd29n%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.

[go-nuts] Unique GO language features

2020-08-21 Thread joseph.p...@gmail.com

I really like the 'defer' statement and think it would be a useful addition 
to other programming languages.

The feature where GO performs escape analysis and promotes stack variables 
to the heap: Did that originate with GO or was it first implemented 
elsewhere?

Thanks,

Joe

-- 
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/aa60d506-7b98-49fd-8017-9601c18ff09dn%40googlegroups.com.

Re: [go-nuts] Re: go test -timeout 30m can this be set inside Go code? disable timeouts programmatically?

2020-08-21 Thread Mike P

Actually, that doesn't work. My apologies. If I figure it out, I will reply.

On Fri, Aug 21, 2020 at 11:27 AM Mike P  wrote:

> I was able to accomplish this via the flag library in my testing function:
>
> flag.Set("test.timeout", "30m0s")
>
> 
>
> I found that being read from here:
>
> https://github.com/golang/go/blob/d21953df047868ed3bcfd0172a6c1672642f5b4a/src/cmd/go/testdata/script/test_timeout.txt#L22
>
> So then I just changed the Lookup() function to the Set() function. Here's
> my working example when using go test to execute some terragrunt /
> terraform tests:
>
> func TestBasicRun(t *testing.T) {
> flag.Set("test.timeout", "30m0s")
> fmt.Println("timeout: " + flag.Lookup("test.timeout").Value.String())
>
> terraformOptions := &terraform.Options{
> TerraformBinary: "terragrunt",
> TerraformDir:"./basic-run",
> Lock:true,
> }
>
> defer terraform.Destroy(t, terraformOptions)
>
> terraform.InitAndApplyAndIdempotent(t, terraformOptions)
> }
>
> 
>
> I think you can disable it by setting it to something like:
>
> "0m0s"
> 
> On Monday, January 20, 2020 at 7:03:36 PM UTC-6 Jason E. Aten wrote:
>
>> I have a long running test where I would like to set the testing package
>> timeout to 30 minutes from with the my_test.go code.
>>
>> This would prevent me from forgetting to add the timeout flag, and then
>> discovering 10 minutes later that it was needed.
>>
>> Is this possible? Or just a way to disable the timeouts all together from
>> Go _test.go code.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/so01nDZLnIQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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/5a36865f-436b-4fab-8d44-64795e77a5bcn%40googlegroups.com
> 
> .
>


-- 

Mike Pescetto
Senior Site Reliability Engineer
mpesce...@opploans.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/CA%2B-r-KXuToCbZ2Wh9xDqk%3DP5Kw1XBk4dAwEWOJrOrpdNuNZf1g%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.

[go-nuts] Re: go test -timeout 30m can this be set inside Go code? disable timeouts programmatically?

2020-08-21 Thread Mike P

I was able to accomplish this via the flag library in my testing function:

flag.Set("test.timeout", "30m0s")


I found that being read from here:
https://github.com/golang/go/blob/d21953df047868ed3bcfd0172a6c1672642f5b4a/src/cmd/go/testdata/script/test_timeout.txt#L22

So then I just changed the Lookup() function to the Set() function. Here's 
my working example when using go test to execute some terragrunt / 
terraform tests:

func TestBasicRun(t *testing.T) {
flag.Set("test.timeout", "30m0s")
fmt.Println("timeout: " + flag.Lookup("test.timeout").Value.String())

terraformOptions := &terraform.Options{
TerraformBinary: "terragrunt",
TerraformDir:"./basic-run",
Lock:true,
}

defer terraform.Destroy(t, terraformOptions)

terraform.InitAndApplyAndIdempotent(t, terraformOptions)
}


I think you can disable it by setting it to something like: 

"0m0s"
On Monday, January 20, 2020 at 7:03:36 PM UTC-6 Jason E. Aten wrote:

> I have a long running test where I would like to set the testing package 
> timeout to 30 minutes from with the my_test.go code.
>
> This would prevent me from forgetting to add the timeout flag, and then 
> discovering 10 minutes later that it was needed.
>
> Is this possible? Or just a way to disable the timeouts all together from 
> Go _test.go code.
>

-- 
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/5a36865f-436b-4fab-8d44-64795e77a5bcn%40googlegroups.com.

Re: [go-nuts] [string] multiline stirng and break line "\n"

Hey,

the `-quotes denote a "raw string literal". Escape-sequences in raw string
literals are not interpreted - that's basically their purpose. So `t2`
contains the literal two-byte sequence `\n`. You can see that in the output
of `fmt.Println`, the newline is a 10, but t2 does not contain a 10, but
a 92 ("\") and 110 ("n") instead.

If you want a raw string literal to contain an actual line-break, you have
to put a line-break (not a line-break escape sequence) into it:
https://play.golang.org/p/9DYfkVDk5RC

Hope that helps

On Fri, Aug 21, 2020 at 6:01 PM 'Guilherme Dalmarco' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Why *bytes.IndexByte *can not find '\n' in multiline string?
>
> package main
>
> import (
> "bytes"
> "fmt"
> )
>
> func main() {
> t1 := []byte("TEST\n")
> t2 := []byte(`TEST\n`)
> t3 := byte('\n')
>
> fmt.Println(t1)
> fmt.Println(t2)
> fmt.Println(t3)
>
> fmt.Println(bytes.IndexByte(t1, t3))
> fmt.Println(bytes.IndexByte(t2, t3))
> }
>
> --
> 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/925e3a5a-0775-44a4-8428-42b077a6be1dn%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/CAEkBMfHQN4wcFg_zhXprE8ZEFvnbzpS7ETg01Ex9yyqrTh6aSQ%40mail.gmail.com.

Re: [go-nuts] [string] multiline stirng and break line "\n"

2020-08-21 Thread Jan Mercl

Variable t2 has no newline in its value.

On Fri, Aug 21, 2020, 18:01 'Guilherme Dalmarco' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Why *bytes.IndexByte *can not find '\n' in multiline string?
>
> package main
>
> import (
> "bytes"
> "fmt"
> )
>
> func main() {
> t1 := []byte("TEST\n")
> t2 := []byte(`TEST\n`)
> t3 := byte('\n')
>
> fmt.Println(t1)
> fmt.Println(t2)
> fmt.Println(t3)
>
> fmt.Println(bytes.IndexByte(t1, t3))
> fmt.Println(bytes.IndexByte(t2, t3))
> }
>
> --
> 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/925e3a5a-0775-44a4-8428-42b077a6be1dn%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/CAA40n-VCDxeLJSDBvGuZzZyii5TBVsu_ZNH4Y%2BuAP_fyYE27Lg%40mail.gmail.com.

[go-nuts] [string] multiline stirng and break line "\n"

2020-08-21 Thread 'Guilherme Dalmarco' via golang-nuts

Why *bytes.IndexByte *can not find '\n' in multiline string?

package main

import (
"bytes"
"fmt"
)

func main() {
t1 := []byte("TEST\n")
t2 := []byte(`TEST\n`)
t3 := byte('\n')

fmt.Println(t1)
fmt.Println(t2)
fmt.Println(t3)

fmt.Println(bytes.IndexByte(t1, t3))
fmt.Println(bytes.IndexByte(t2, t3))
}

-- 
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/925e3a5a-0775-44a4-8428-42b077a6be1dn%40googlegroups.com.

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

2020-08-21 Thread 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 ex

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