Re: [go-nuts] Re: Generics and parentheses

[burak serdar]

On Tue, Jul 14, 2020 at 10:14 PM Ian Lance Taylor  wrote:
>
> On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
> wrote:
> >
> > This feels a little better, but honestly I'm still all for angle brackets 
> > or like Watson suggested, guillamets.
> >
> > fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
> > fn[T1](fn2[T2](fn3[T3](v))) // 2
> > fn(fn2(fn3(v))) // 3
> > fn«T1»(fn2«T2»(fn3«T3»v)))  // 4
> >
> > To me, with a background in C++ and Typescript and a little bit of Rust, #3 
> > and #4 are just natural and easier to read.
>
> The advantage of parentheses is that the language already uses
> parentheses for lists in various places.  Of course that is also the
> disadvantage.
>
> When considering something other than parentheses, I encourage people
> to look for objective reasons why one syntax is better than another.
> It's going to be different from other aspects of the language.  So
> what reason would we have for preferring one syntax over another?
>
> For example:
>
> Robert already gave reasons why square brackets are better than angle 
> brackets.
>
> The disadvantage of guillemets is that they are hard to type on many
> keyboards.  So to me either square brackets or angle brackets would be
> better than guillemets.
>
> The disadvantage of a two character sequence such as <: :> is that it
> is more typing.  So again either square brackets or angle brackets
> seem to me to be better.


A two-character sequence like <: T :> may be more typing, but the
two-character sequence like [[ T ]] is easier to type than that and
eliminates the ambiguity. To me, it is easier to read as well, but
that's of course subjective.

>
> An example of a reason that square brackets might be a poor choice
> would be ambiguous parsing, or cases where the code is harder to read.
>
> It's true that some other languages use angle brackets, but Go already
> does many things differently.  That is only a minor advantage for
> angle brackets.  To me at least it does not outweigh the
> disadvantages.
>
> In short, please try to provide reasons for a different syntax.  "It
> looks good" is a valid reason, but please try to explain why it looks
> better than square brackets or parentheses.
>
> Thanks.
>
> 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/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%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/CAMV2RqoOFM_vFu63xs0_eWxwuB89h_w82U7o5eE4gtDbJht76A%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Paul Johnston]

If the generic expression  was always attached/constrained to the "type" 
or "func" keyword (rather than the type or function name), perhaps this 
would decrease the lookahead problems with lexing?  For example:

*type Point struct {*
*x, y int*
*data T*
*}*

*type Transformer interface {*
*Transform(R) S*
*}*

*func Stringify(s []T) string {*
*}*

*type Vector []T*



On Tuesday, July 14, 2020 at 10:45:41 PM UTC-6 ren...@ix.netcom.com wrote:

> My opinion is that every major language (no flames please… lots of 
> developers write lots of programs and make money doing it) that supports 
> generics uses < > for generic types, so Go should too - since there is no 
> reason to deviate from this other than to avoid changes to the parser. 
> Seems better to pay this cost once - rather than every Go program that uses 
> generics being harder to read for eternity (especially for those readers 
> that use a lot of languages).
>
> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  wrote:
> > 
> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
> wrote:
> >> 
> >> This feels a little better, but honestly I'm still all for angle 
> brackets or like Watson suggested, guillamets.
> >> 
> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
> >> fn[T1](fn2[T2](fn3[T3](v))) // 2
> >> fn(fn2(fn3(v))) // 3
> >> fn«T1»(fn2«T2»(fn3«T3»v))) // 4
> >> 
> >> To me, with a background in C++ and Typescript and a little bit of 
> Rust, #3 and #4 are just natural and easier to read.
> > 
> > The advantage of parentheses is that the language already uses
> > parentheses for lists in various places. Of course that is also the
> > disadvantage.
> > 
> > When considering something other than parentheses, I encourage people
> > to look for objective reasons why one syntax is better than another.
> > It's going to be different from other aspects of the language. So
> > what reason would we have for preferring one syntax over another?
> > 
> > For example:
> > 
> > Robert already gave reasons why square brackets are better than angle 
> brackets.
> > 
> > The disadvantage of guillemets is that they are hard to type on many
> > keyboards. So to me either square brackets or angle brackets would be
> > better than guillemets.
> > 
> > The disadvantage of a two character sequence such as <: :> is that it
> > is more typing. So again either square brackets or angle brackets
> > seem to me to be better.
> > 
> > An example of a reason that square brackets might be a poor choice
> > would be ambiguous parsing, or cases where the code is harder to read.
> > 
> > It's true that some other languages use angle brackets, but Go already
> > does many things differently. That is only a minor advantage for
> > angle brackets. To me at least it does not outweigh the
> > disadvantages.
> > 
> > In short, please try to provide reasons for a different syntax. "It
> > looks good" is a valid reason, but please try to explain why it looks
> > better than square brackets or parentheses.
> > 
> > Thanks.
> > 
> > Ian
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%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/e2459352-ab61-4bba-99a3-215496faaab5n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[robert engels]

My opinion is that every major language (no flames please… lots of developers 
write lots of programs and make money doing it) that supports generics uses < > 
for generic types, so Go should too - since there is no reason to deviate from 
this other than to avoid changes to the parser. Seems better to pay this cost 
once - rather than every Go program that uses generics being harder to read for 
eternity (especially for those readers that use a lot of languages).

> On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  wrote:
> 
> On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
> wrote:
>> 
>> This feels a little better, but honestly I'm still all for angle brackets or 
>> like Watson suggested, guillamets.
>> 
>> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
>> fn[T1](fn2[T2](fn3[T3](v))) // 2
>> fn(fn2(fn3(v))) // 3
>> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4
>> 
>> To me, with a background in C++ and Typescript and a little bit of Rust, #3 
>> and #4 are just natural and easier to read.
> 
> The advantage of parentheses is that the language already uses
> parentheses for lists in various places.  Of course that is also the
> disadvantage.
> 
> When considering something other than parentheses, I encourage people
> to look for objective reasons why one syntax is better than another.
> It's going to be different from other aspects of the language.  So
> what reason would we have for preferring one syntax over another?
> 
> For example:
> 
> Robert already gave reasons why square brackets are better than angle 
> brackets.
> 
> The disadvantage of guillemets is that they are hard to type on many
> keyboards.  So to me either square brackets or angle brackets would be
> better than guillemets.
> 
> The disadvantage of a two character sequence such as <: :> is that it
> is more typing.  So again either square brackets or angle brackets
> seem to me to be better.
> 
> An example of a reason that square brackets might be a poor choice
> would be ambiguous parsing, or cases where the code is harder to read.
> 
> It's true that some other languages use angle brackets, but Go already
> does many things differently.  That is only a minor advantage for
> angle brackets.  To me at least it does not outweigh the
> disadvantages.
> 
> In short, please try to provide reasons for a different syntax.  "It
> looks good" is a valid reason, but please try to explain why it looks
> better than square brackets or parentheses.
> 
> Thanks.
> 
> 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/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%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/825D82DD-C595-415D-B0C6-7BE090A015C7%40ix.netcom.com.

Re: [go-nuts] Re: Generics and parentheses

[Ian Lance Taylor]

On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  wrote:
>
> This feels a little better, but honestly I'm still all for angle brackets or 
> like Watson suggested, guillamets.
>
> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
> fn[T1](fn2[T2](fn3[T3](v))) // 2
> fn(fn2(fn3(v))) // 3
> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4
>
> To me, with a background in C++ and Typescript and a little bit of Rust, #3 
> and #4 are just natural and easier to read.

The advantage of parentheses is that the language already uses
parentheses for lists in various places.  Of course that is also the
disadvantage.

When considering something other than parentheses, I encourage people
to look for objective reasons why one syntax is better than another.
It's going to be different from other aspects of the language.  So
what reason would we have for preferring one syntax over another?

For example:

Robert already gave reasons why square brackets are better than angle brackets.

The disadvantage of guillemets is that they are hard to type on many
keyboards.  So to me either square brackets or angle brackets would be
better than guillemets.

The disadvantage of a two character sequence such as <: :> is that it
is more typing.  So again either square brackets or angle brackets
seem to me to be better.

An example of a reason that square brackets might be a poor choice
would be ambiguous parsing, or cases where the code is harder to read.

It's true that some other languages use angle brackets, but Go already
does many things differently.  That is only a minor advantage for
angle brackets.  To me at least it does not outweigh the
disadvantages.

In short, please try to provide reasons for a different syntax.  "It
looks good" is a valid reason, but please try to explain why it looks
better than square brackets or parentheses.

Thanks.

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/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%40mail.gmail.com.

[go-nuts] Re: Generics and parentheses

[mac3n]

I'm partial to [], which was used for generics in the Tartan language 
(1978). For example 

generic func F[Mult: Int](X:Int) y:Int: begin y := Mult * X end


https://apps.dtic.mil/dtic/tr/fulltext/u2/a062815.pdf, page 4

-- 
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/2c052dbd-8825-4541-939d-77d41551c0e2o%40googlegroups.com.

[go-nuts] Ignite go library

[Wesley]

Hi

Is there any thin client for Ignite by go?
https://ignite.apache.org/docs-and-apis.html

I didn't see the official one.

Thank you.

--
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/5879d66e-a8af-bdf0-888d-bb5a330f4f9f%40freenetMail.de.

Re: [go-nuts] Re: Generics and parentheses

[Ian Lance Taylor]

On Tue, Jul 14, 2020 at 8:31 PM  wrote:
>
> One way to distinguish between type A[N] E and type A [N]E is to be more 
> space-sensitive and, for example, disallow whitespace between a type name and 
> the opening square bracket when it signifies type parameters.

I would be extremely reluctant to make the syntax depend on invisible
whitespace.  The syntax already depends on line breaks, but at least
line breaks are very visible.  Spacing within a line can be hard to
see and it would be quite easy to make mistakes.

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/CAOyqgcVSMhxJRU--262DY2UJQ%3DGpRSaM09Hn-0q-7dKdhGNeEA%40mail.gmail.com.

Re: [go-nuts] Re: Generics and parentheses

[Ian Lance Taylor]

On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote:
>
> Guillamets are worth consideration. They are common on European keyboards and 
> avoid all the syntax ambiguities.

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use

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/CAOyqgcXLzEX6a2cxOUCY8EWqqR8e4cSK-qYzxPCkBBoG4B%2B5dw%40mail.gmail.com.

[go-nuts] Re: Generics and parentheses

[faiface2202]

One way to distinguish between type A[N] E and type A [N]E is to be more 
space-sensitive and, for example, disallow whitespace between a type name 
and the opening square bracket when it signifies type parameters.

Dňa utorok, 14. júla 2020 23:56:01 UTC+2 gri napísal(a):
>
> We have received a variety of feedback on the generics draft design 
> 
>  
> (blog ). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> , and eventually 
> in the playground .
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
> values
>
> (w)(z)
>
> In Go, type information is not available at compile time. For instance, in 
> this case, any of the identifiers may be declared in another file that has 
> not even been parsed yet.
>
>

-- 
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/6150dc01-0add-4bee-b3cc-4bc4429d8f11o%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Ahmed (OneOfOne) W.]

This feels a little better, but honestly I'm still all for angle brackets 
or like Watson suggested, guillamets.




*fn(T1)(fn2(T2)(fn3(T3)(v))) // 1fn[T1](fn2[T2](fn3[T3](v))) // 
2fn(fn2(fn3(v))) // 3fn«T1»(fn2«T2»(fn3«T3»v)))  // 4*

To me, with a background in C++ and Typescript and a little bit of Rust, #3 
and #4 are just natural and easier to read.

Regards,
Ahmed W.
On Tuesday, July 14, 2020 at 9:44:53 PM UTC-5 watso...@gmail.com wrote:

> Guillamets are worth consideration. They are common on European keyboards 
> and avoid all the syntax ambiguities.
>
> While a technical violation of compatibility by adding new reserved 
> characters, in practice I doubt this will be an issue given the semantics 
> of guillamets.
>
> Sincerely,
> Watson 
>

-- 
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/f060465f-9e61-43f6-b124-22c394dc67d5n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[David Riley]

On Jul 14, 2020, at 5:54 PM, 'Robert Griesemer' via golang-nuts 
 wrote:
> 
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
> 
>   type A[type N] E
> 
> (When we originally dismissed square brackets, the type keyword was not yet 
> on the table.)
> 
> Furthermore, the ambiguities that arise with parentheses appear not to arise 
> with square brackets. Here are some examples where extra parentheses are not 
> needed with square brackets:
> 
>   using () using []
>   func f((T(int))  func f(T[int])
>   struct{ (T(int)) }   struct{ T[int] }
>   interface{ (T(int)) }interface{ T[int] }
>   [](T(int)){} []T[int]{}

Just my $0.02: I really like this.  Thank you for responding to feedback, and I 
look forward to trying the new syntax out!


- 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/6C145CFD-7A43-4BAA-87AA-5E3AA00C068C%40gmail.com.

[go-nuts] Re: Generics and parentheses

[Watson Ladd]

Guillamets are worth consideration. They are common on European keyboards and 
avoid all the syntax ambiguities.

While a technical  violation of compatibility by adding new reserved 
characters, in practice I doubt this will be an issue given the semantics of 
guillamets.

Sincerely,
Watson 

-- 
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/7a8614fe-6329-4d3b-9570-b7dd54785e5eo%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Doug]

The square bracket-based syntax feels much more readable to me, so it's a 
welcome change!

Based on my dev background I'm still partial to angle brackets and had an 
idea for disambiguating function calls. We could put the type information 
as the first data *inside* the parens, so a generic function invocation 
would become:
w( z)

This may not be the right forum to discuss the idea, but figured I'd throw 
it out there.

Thanks,
Doug

On Tuesday, July 14, 2020 at 4:56:01 PM UTC-5, gri wrote:
>
> We have received a variety of feedback on the generics draft design 
> 
>  
> (blog ). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> , and eventually 
> in the playground .
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
> values
>
> (w)(z)
>
> In Go, type information is not available at compile time. For instance, in 
> this case, any of the identifiers may be declared in another file that has 
> not even been parsed yet.
>
>

-- 
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/4725dd75-eef7-4794-ab04-44e9335a9d91o%40googlegroups.com.

Re: [go-nuts] Re: Quick question about calling Set-Cookie twice in a row

[Marcin Romaszewicz]

The Go http code calls Header.Add() on your cookie, and Header.Add will
concatenate values together. If you want replacement semantics, you'll have
to clearout the "Set-Cookie" header on the response, or only add your final
cookie.

On Tue, Jul 14, 2020 at 4:58 PM B Carr  wrote:

> In my application, the most recent cookie value with the same name is
> returned on the next request.
>
> On Tuesday, July 14, 2020 at 1:54:56 PM UTC-6, atd...@gmail.com wrote:
>>
>> Hello,
>>
>> As I am writing some tests, I was wondering what should be the correct
>> behavior when http.SetCookie is called twice with cookies of a same name
>> but different values.
>>
>> For example, what should a user-agent see as the cookie value and hence,
>> what should it return back to the server with the next request?
>>
>> https://play.golang.org/p/nYDmcFcd8Qj
>>
>> Many 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/442794c0-c906-4472-ba8a-6017a22e19e8o%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/CA%2Bv29LvaPxnX8y5qEvQV1r1UaUtfWuxZTOL-CNaff%3DeLCwc7SQ%40mail.gmail.com.

[go-nuts] Re: Quick question about calling Set-Cookie twice in a row

[B Carr]

In my application, the most recent cookie value with the same name is 
returned on the next request.

On Tuesday, July 14, 2020 at 1:54:56 PM UTC-6, atd...@gmail.com wrote:
>
> Hello,
>
> As I am writing some tests, I was wondering what should be the correct 
> behavior when http.SetCookie is called twice with cookies of a same name 
> but different values.
>
> For example, what should a user-agent see as the cookie value and hence, 
> what should it return back to the server with the next request?
>
> https://play.golang.org/p/nYDmcFcd8Qj
>
> Many 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/442794c0-c906-4472-ba8a-6017a22e19e8o%40googlegroups.com.

[go-nuts] Help Wanted: Implement seek support in FLAC library

[tslocum]

Hi all, if you or someone you know is interested in tinkering with audio 
decoding, please take a look at this issue: 
https://github.com/mewkiz/flac/issues/16

Partial seek support may be available here: 
https://github.com/mewkiz/flac/tree/seek

-- 
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/ef0d08e1-bef8-4165-b2df-8ca0961dac0eo%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Harald Weidner]

Hello,

> A typical computer keyboard provides four easily accessible pairs of
> single-character symmetrical "brackets": parentheses ( and ), square
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses
> curly braces to delineate code blocks, composite literals, and some
> composite types, making it virtually impossible to use them for generics
> without severe syntactic problems. Angle brackets require unbounded parser
> look-ahead or type information in certain situations (see the end of this
> e-mail for an example). This leaves us with parentheses and square
> brackets.

Another option would be the introduction of a new two-letter
"bracket" operator, for example <: and :> . This could be parsed
without symbol/type information and even without the "type" keyword.

That said, I'm fine with any syntax. Thank you for your work on
generics!

Regards,
Harald

-- 
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/20200714223122.GA6955%40hweidner.de.

[go-nuts] Re: Generics and parentheses

['gri' via golang-nuts]

Correction: The last paragraph in the post below should have said: "In Go, 
type information is not available at *parse* time". (Of course, type 
information is available at compile time.)

On Tuesday, July 14, 2020 at 2:56:01 PM UTC-7 gri wrote:

> We have received a variety of feedback on the generics draft design 
> 
>  
> (blog ). Thanks to everyone 
> who took the time to read it, play with generics code in the playground 
> , file issues, and send us their thoughts.
>
> Not unexpectedly, many people raised concerns about the syntax, 
> specifically the choice of parentheses for type parameter declarations and 
> generic type and function instantiations.
>
> A typical computer keyboard provides four easily accessible pairs of 
> single-character symmetrical "brackets": parentheses ( and ), square 
> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
> curly braces to delineate code blocks, composite literals, and some 
> composite types, making it virtually impossible to use them for generics 
> without severe syntactic problems. Angle brackets require unbounded parser 
> look-ahead or type information in certain situations (see the end of this 
> e-mail for an example). This leaves us with parentheses and square 
> brackets. Unadorned square brackets cause ambiguities in type declarations 
> of arrays and slices, and to a lesser extent when parsing index 
> expressions. Thus, early on in the design, we settled on parentheses as 
> they seemed to provide a Go-like feel and appeared to have the fewest 
> problems.
>
> As it turned out, to make parentheses work well and for 
> backward-compatibility, we had to introduce the type keyword in type 
> parameter lists. Eventually, we found additional parsing ambiguities in 
> parameter lists, composite literals, and embedded types which required more 
> parentheses to resolve them. Still, we decided to proceed with parentheses 
> in order to focus on the bigger design issues.
>
> The time has come to revisit this early decision. If square brackets alone 
> are used to declare type parameters, the array declaration
>
> type A [N]E
>
> cannot be distinguished from the generic type declaration
>
> type A[N] E
>
> But if we are comfortable with the extra type keyword, the ambiguity 
> disappears:
>
> type A[type N] E
>
> (When we originally dismissed square brackets, the type keyword was not 
> yet on the table.)
>
> Furthermore, the ambiguities that arise with parentheses appear not to 
> arise with square brackets. Here are some examples where extra parentheses 
> are not needed with square brackets:
>
> using () using []
>
> func f((T(int))  func f(T[int])
>
> struct{ (T(int)) }   struct{ T[int] }
>
> interface{ (T(int)) }interface{ T[int] }
>
> [](T(int)){} []T[int]{}
>
> To test this better understanding, and to get a feel for this alternative 
> notation, we will begin to make changes to our prototype implementation 
> such that it accepts either parentheses or square brackets (only one or the 
> other) in a generic Go package. Those changes will first appear as commits 
> to the dev.go2go branch 
> , and eventually 
> in the playground .
>
> If square brackets don't lead to unforeseen issues, we have another fully 
> explored notation to choose from, which will allow us to make a more 
> informed decision.
>
> - gri, iant
>
> PS: For ambiguities with angle brackets consider the assignment
>
> a, b = w < x, y > (z)
>
> Without type information, it is impossible to decide whether the 
> right-hand side of the assignment is a pair of expressions
>
> (w < x), (y > (z))
>
> or whether it is a generic function invocation that returns two result 
> values
>
> (w)(z)
>
> In Go, type information is not available at compile time. For instance, in 
> this case, any of the identifiers may be declared in another file that has 
> not even been parsed yet.
>
>

-- 
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/97a2914f-3e54-4994-974f-135e11f7n%40googlegroups.com.

[go-nuts] Generics and parentheses

['Robert Griesemer' via golang-nuts]

We have received a variety of feedback on the generics draft design

(blog ). Thanks to everyone who
took the time to read it, play with generics code in the playground
, file issues, and send us their thoughts.

Not unexpectedly, many people raised concerns about the syntax,
specifically the choice of parentheses for type parameter declarations and
generic type and function instantiations.

A typical computer keyboard provides four easily accessible pairs of
single-character symmetrical "brackets": parentheses ( and ), square
brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses
curly braces to delineate code blocks, composite literals, and some
composite types, making it virtually impossible to use them for generics
without severe syntactic problems. Angle brackets require unbounded parser
look-ahead or type information in certain situations (see the end of this
e-mail for an example). This leaves us with parentheses and square
brackets. Unadorned square brackets cause ambiguities in type declarations
of arrays and slices, and to a lesser extent when parsing index
expressions. Thus, early on in the design, we settled on parentheses as
they seemed to provide a Go-like feel and appeared to have the fewest
problems.

As it turned out, to make parentheses work well and for
backward-compatibility, we had to introduce the type keyword in type
parameter lists. Eventually, we found additional parsing ambiguities in
parameter lists, composite literals, and embedded types which required more
parentheses to resolve them. Still, we decided to proceed with parentheses
in order to focus on the bigger design issues.

The time has come to revisit this early decision. If square brackets alone
are used to declare type parameters, the array declaration

type A [N]E

cannot be distinguished from the generic type declaration

type A[N] E

But if we are comfortable with the extra type keyword, the ambiguity
disappears:

type A[type N] E

(When we originally dismissed square brackets, the type keyword was not yet
on the table.)

Furthermore, the ambiguities that arise with parentheses appear not to
arise with square brackets. Here are some examples where extra parentheses
are not needed with square brackets:

using () using []

func f((T(int))  func f(T[int])

struct{ (T(int)) }   struct{ T[int] }

interface{ (T(int)) }interface{ T[int] }

[](T(int)){} []T[int]{}

To test this better understanding, and to get a feel for this alternative
notation, we will begin to make changes to our prototype implementation
such that it accepts either parentheses or square brackets (only one or the
other) in a generic Go package. Those changes will first appear as commits
to the dev.go2go branch
, and eventually in
the playground .

If square brackets don't lead to unforeseen issues, we have another fully
explored notation to choose from, which will allow us to make a more
informed decision.

- gri, iant

PS: For ambiguities with angle brackets consider the assignment

a, b = w < x, y > (z)

Without type information, it is impossible to decide whether the right-hand
side of the assignment is a pair of expressions

(w < x), (y > (z))

or whether it is a generic function invocation that returns two result
values

(w)(z)

In Go, type information is not available at compile time. For instance, in
this case, any of the identifiers may be declared in another file that has
not even been parsed yet.

-- 
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/CAKy0tf4agu1nNdwc%3DeZQt-KpvrD8XcFm502x46tkriz3gEJUXg%40mail.gmail.com.

[go-nuts] Quick question about calling Set-Cookie twice in a row

[atd...@gmail.com]

Hello,

As I am writing some tests, I was wondering what should be the correct 
behavior when http.SetCookie is called twice with cookies of a same name 
but different values.

For example, what should a user-agent see as the cookie value and hence, 
what should it return back to the server with the next request?

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

Many 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/80bb88c1-dcad-486f-9448-dae1fada405ao%40googlegroups.com.

[go-nuts] [security] Go 1.14.5 and Go 1.13.13 are released

[Katie Hockman]

Hi gophers,

We have just released Go 1.14.5 and Go 1.13.13 to address two recently
reported security issues. We recommend that all users update to one of
these releases (if you’re not sure which, choose Go 1.14.5).

   -

   Data race in certain net/http servers including ReverseProxy


Servers where the Handler concurrently reads the request body and writes a
response can encounter a data race and crash. The httputil.ReverseProxy
Handler is affected.
Thanks to Mikael Manukyan, Andrew Kutz, Dave McClure, Tim Downey, Clay
Kauzlaric, and Gabe Rosenhouse for reporting this issue.
This issue is CVE-2020-15586 and Go issue golang.org/issue/34902.



   -

   X.509 verification ignores provided EKUs on Windows


On Windows, if VerifyOptions.Roots
 is nil,
Certificate.Verify
 does not check
the EKU requirements specified in VerifyOptions.KeyUsages
.
Thanks to Niall Newman for reporting this issue.
This issue is CVE-2020-14039 and Go issue golang.org/issue/39360.


The upcoming Go 1.15rc1 release will also include the fixes above.

We would also like to thank Andy Lindeman, who reported a cross-site
scripting vulnerability and a CSP bypass in pkg.go.dev, now fixed.

Downloads are available at https://golang.org/dl for all supported
platforms.

Thank you,

Katie and Filippo on behalf of the Go team

-- 
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/CALvTBvdYO0D-Ri0i_wY-%2BvSPdHa8yGbEwfos4Nu5mZa9YQQrKQ%40mail.gmail.com.

[go-nuts] [security] Go 1.14.5 and Go 1.13.13 are released

[Katie Hockman]

Hi gophers,

We have just released Go 1.14.5 and Go 1.13.13 to address two recently
reported security issues. We recommend that all users update to one of
these releases (if you’re not sure which, choose Go 1.14.5).


   -

   Data race in certain net/http servers including ReverseProxy

   Servers where the Handler concurrently reads the request body and writes
   a response can encounter a data race and crash. The httputil.ReverseProxy
   Handler is affected.

Thanks to Mikael Manukyan, Andrew Kutz, Dave McClure, Tim Downey, Clay
Kauzlaric, and Gabe Rosenhouse for reporting this issue.
This issue is CVE-2020-15586 and Go issue golang.org/issue/34902.



   -

   X.509 verification ignores provided EKUs on Windows

   On Windows, if VerifyOptions.Roots
    is nil,
   Certificate.Verify
    does not
   check the EKU requirements specified in VerifyOptions.KeyUsages
   .

Thanks to Niall Newman for reporting this issue.
This issue is CVE-2020-14039 and Go issue golang.org/issue/39360.


The upcoming Go 1.15rc1 release will also include the fixes above.

We would also like to thank Andy Lindeman, who reported a cross-site
scripting vulnerability and a CSP bypass in pkg.go.dev, now fixed.

Downloads are available at https://golang.org/dl for all supported
platforms.

Thank you,

Katie and Filippo on behalf of the Go team

-- 
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/CALvTBvedjXz%2BYaJLmakLJOoDwQ%2B0c%3Dth5PS9H_13pqpKwbHGBA%40mail.gmail.com.

Re: [go-nuts] Re: golang time.Now().Format with milliseconds without dot in string

[Jake Montgomery]

I agree, it seems like an unfortunate oversight. You can do it without the 
slice tricks: https://play.golang.org/p/tNAPOcQqApN
It does take an additional Sprintf() though.

On Tuesday, July 14, 2020 at 8:40:18 AM UTC-4, Vasiliy Tolstov wrote:
>
> вт, 14 июл. 2020 г. в 15:17, Jake Montgomery  >: 
> > 
> > Why not just remove the dot? You know where it is: 
> https://play.golang.org/p/ZHqHTOeA7HQ 
> > Perhaps there is a better way, but this seems to work. 
> > 
>
> Yes, thanks. My question mostly - why format time to some intermediate 
> string that needs to be preprocessed before usage =) 
> Format means that you get a needed sting and not that you must use 
> slice manipulation. 
>
> -- 
> Vasiliy Tolstov, 
> e-mail: v.to...@selfip.ru  
>

-- 
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/a96b94bc-ab09-488f-9a7a-5622e6935a1eo%40googlegroups.com.

[go-nuts] Considering dropping GO386=387

['Austin Clements' via golang-nuts]

Hi everyone. We’re exploring the possibility of dropping 387 floating-point
support and requiring SSE2 support for GOARCH=386 in the native gc
compiler, potentially in Go 1.16. This would raise the minimum GOARCH=386
requirement to the Intel Pentium 4 (released in 2000) or AMD Opteron/Athlon
64 (released in 2003).

There are several reasons we’re considering this:

   1. While 387 support isn’t a huge maintenance burden, it does take time
   away from performance and feature work and represents a fair amount of
   latent complexity.
   2. 387 support has been a regular source of bugs (#36400
   , #27516
   , #22429 ,
   #17357 , #13923
   , #12970 ,
   #4798 , just to name a few).
   3. 387 bugs often go undetected for a long time because we don’t have
   builders that support only 387 (so unsupported instructions can slip in
   unnoticed).
   4. Raising the minimum requirement to SSE2 would allow us to also assume
   many other useful architectural features, such as proper memory fences and
   128 bit registers, which would simplify the compiler and runtime and allow
   for much more efficient implementations of core functions like memmove on
   386.
   5. We’re exploring switching to a register-based calling convention in
   Go 1.16, which promises significant performance improvements, but retaining
   387 support will definitely complicate this and slow our progress.


The gccgo toolchain will continue to support 387 floating-point, so this
remains an option for projects that absolutely must use 387 floating-point.

We’d like to know if there are still significant uses of GO386=387,
particularly for which using gccgo would not be a viable option.

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/CALgmw190ym7heSN2pb3xS%2BiA_UN97aP-2KW4tqC_9FFtYt9W3Q%40mail.gmail.com.

Re: [go-nuts] Re: golang time.Now().Format with milliseconds without dot in string

[Vasiliy Tolstov]

вт, 14 июл. 2020 г. в 15:17, Jake Montgomery :
>
> Why not just remove the dot? You know where it is: 
> https://play.golang.org/p/ZHqHTOeA7HQ
> Perhaps there is a better way, but this seems to work.
>

Yes, thanks. My question mostly - why format time to some intermediate
string that needs to be preprocessed before usage =)
Format means that you get a needed sting and not that you must use
slice manipulation.

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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/CACaajQvgos6dd2B-kH-S7JKbDvFU7cVopOZYDAsEQH1TU1av_A%40mail.gmail.com.

[go-nuts] Re: golang time.Now().Format with milliseconds without dot in string

[Jake Montgomery]

Why not just remove the dot? You know where it is: 
https://play.golang.org/p/ZHqHTOeA7HQ
Perhaps there is a better way, but this seems to work. 

On Tuesday, July 14, 2020 at 7:00:02 AM UTC-4, Vasiliy Tolstov wrote:
>
> Hi! I'm read several times godoc about the time package but have now 
> way to deal with it. 
> I need to output strings with format MMDDHHMMSSMILLISEC without 
> dot in string. But go able to output milliseconds only in case of .000 
>
>
> -- 
> Vasiliy Tolstov, 
> e-mail: v.to...@selfip.ru  
>

-- 
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/eb0a4ef8-19ed-46aa-be3c-257387795174o%40googlegroups.com.

[go-nuts] golang time.Now().Format with milliseconds without dot in string

[Vasiliy Tolstov]

Hi! I'm read several times godoc about the time package but have now
way to deal with it.
I need to output strings with format MMDDHHMMSSMILLISEC without
dot in string. But go able to output milliseconds only in case of .000


-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

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

Re: [go-nuts] [generics] Type embedding in generic types

['Javier Zunzunegui' via golang-nuts]

Issue openned in https://github.com/golang/go/issues/40199.

Still clarifying my thoughts on embedding types within generics, will 
postpone this debate while I focus on other parts of the proposal and gain 
some more experience using the go2 branch. Not calling for any action here 
at this point. Thanks Ian. 
On Monday, July 13, 2020 at 7:03:35 PM UTC+2 Ian Lance Taylor wrote:

> On Mon, Jul 13, 2020 at 9:15 AM 'Javier Zunzunegui' via golang-nuts
>  wrote:
> >
> > In the context of Type Parameters - Draft Design#generic-types:
> >
> > Type embedding is allowed in the proposed generic changes. Oddly, the 
> current implementation allows for calling methods in the embedded types but 
> not using the method to satisfy an interface (here). That seems like a bug 
> in the implementation.
> >
> > More significantly, it allows for calling not just the methods declared 
> in the interface, but also methods available to the instantiated type but 
> not part of the interface. Example here. I can't see what is the gain in 
> allowing that, and it presents a risk as the interfaces satisfied by types 
> originating from the same generic type will differ not only in the types of 
> the methods, but also i the method names themselves.
> >
> > Would it not be best to not allow embeding in generic types?
>
> At least at first glance these just seem like bugs in the current
> implementation, not in the design draft as such. Would you mind
> opening an issue for these problems? Thanks.
>
> We could ban embedding type parameters, but our hope is to make
> generic types work as much like ordinary types as possible, without
> arbitrary restrictions. The existence of bugs doesn't in itself seem
> like a good enough reason to ban the feature.
>
> 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/d8540f91-94b4-498f-97fe-606f956cea77n%40googlegroups.com.