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

[肖坤超]

You can use ...  As a generic   
 Chinese  你可以使用 ... 作为泛型标志
在2020年8月26日星期三 UTC+8 上午4:59:41 写道：

> Thanks for the note. Please see the discussion at
> https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ .
>
> Ian
>
> On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian
>  wrote:
> >
> > After playing in generics playground with a dozen of cases that came to 
> my mind, IMHO brackets seem to be more clear than parentheses for declaring 
> type parameters. Also using the type keyword before the type parameter 
> reduces the cognitive load drastically.
> >
> > type StateFn[type T] func(T) StateFn[T] // Good
> >
> > vs:
> >
> > type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous 
> one
> >
> > It's hard to say if there are any practical alternatives to brackets - 
> according to the proposal. But angle brackets are not that ugly by 
> themselves.
> >
> > (I'm not sure if this approach is actually possible)
> >
> > The hash/number signs appear in the language specifications just once:
> >
> > type StateFn<#T> func(T) StateFn<#T>
> >
> > And the %T syntax is used to print types:
> >
> > type StateFn<%T> func(T) StateFn<%T>
> >
> > Then, that problematic example would become:
> >
> > a, b = w<#x,y>(z)
> >
> > or:
> >
> > a, b = w<%x,y>(z)
> >
> > On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 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 

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

[Ian Lance Taylor]

Thanks for the note.  Please see the discussion at
https://groups.google.com/d/msg/golang-nuts/iAD0NBz3DYw/VcXSK55XAwAJ .

Ian

On Tue, Aug 25, 2020 at 1:21 PM Kaveh Shahbazian
 wrote:
>
> After playing in generics playground with a dozen of cases that came to my 
> mind, IMHO brackets seem to be more clear than parentheses for declaring type 
> parameters. Also using the type keyword before the type parameter reduces the 
> cognitive load drastically.
>
> type StateFn[type T] func(T) StateFn[T] // Good
>
> vs:
>
> type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous one
>
> It's hard to say if there are any practical alternatives to brackets - 
> according to the proposal. But angle brackets are not that ugly by themselves.
>
> (I'm not sure if this approach is actually possible)
>
> The hash/number signs appear in the language specifications just once:
>
> type StateFn<#T> func(T) StateFn<#T>
>
> And the %T syntax is used to print types:
>
> type StateFn<%T> func(T) StateFn<%T>
>
> Then, that problematic example would become:
>
> a, b = w<#x,y>(z)
>
> or:
>
> a, b = w<%x,y>(z)
>
> On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 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.
>>
>>

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

[Michal Strba]

Thanks for the feedback Ian! I was drawing the idea mostly from Rust, which
already does the same thing, but uses "::" instead of a dot and it works
fine there, but sure, it has its drawbacks.

st 22. 7. 2020 o 0:05 Ian Lance Taylor  napísal(a):

> On Tue, Jul 21, 2020 at 8:49 AM  wrote:
> >
> > I feel like you guys missed my suggestion earlier. I will repeat it
> because I think it can be good. What about a dot to separate type
> parameters in specialization?
> >
> > func zero() T {
> > var x T
> > return x
> > }
> >
> > func main() {
> > fmt.Println(zero.()) // . required here
> > }
> >
> > Dot would be required in expressions when type parameters cannot be
> inferred and need to be specified manually.
> >
> > I believe this fixes the syntactic ambiguities and also is consistent
> with the type assertion syntax.
> >
> > What do you think?
>
> Thanks for the note.  I did see the earlier suggestion.
>
> Speaking personally, I think the advantage of angle brackets is that
> some other languages, notably C++ and Java, use them for type
> parameters.  But they use F, not F..  While I see the
> advantage of emulating the C++ and Java syntax for type parameters, I
> don't see the advantage of having a different syntax that is similar
> but not identical.  In my opinion, a similar but different syntax is
> either no better than a more different syntax, or it is actually worse
> because people will keep accidentally typing F when they meant to
> type F..  So I don't see the advantage of ..
>
> You mention the type assertion syntax, but that vague similarity seems
> like another minor drawback, since this syntax would be used for
> instantiation, which is nothing like type assertion.
>
> Just my personal opinion, of course.
>
> 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/CAO6k0utWCFeNk2fC0X8ZzGH2hSVWFz-iRTR%3DZj%3DS%2BSjHvBwc%3Dw%40mail.gmail.com.

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

[Ian Lance Taylor]

On Tue, Jul 21, 2020 at 8:49 AM  wrote:
>
> I feel like you guys missed my suggestion earlier. I will repeat it because I 
> think it can be good. What about a dot to separate type parameters in 
> specialization?
>
> func zero() T {
> var x T
> return x
> }
>
> func main() {
> fmt.Println(zero.()) // . required here
> }
>
> Dot would be required in expressions when type parameters cannot be inferred 
> and need to be specified manually.
>
> I believe this fixes the syntactic ambiguities and also is consistent with 
> the type assertion syntax.
>
> What do you think?

Thanks for the note.  I did see the earlier suggestion.

Speaking personally, I think the advantage of angle brackets is that
some other languages, notably C++ and Java, use them for type
parameters.  But they use F, not F..  While I see the
advantage of emulating the C++ and Java syntax for type parameters, I
don't see the advantage of having a different syntax that is similar
but not identical.  In my opinion, a similar but different syntax is
either no better than a more different syntax, or it is actually worse
because people will keep accidentally typing F when they meant to
type F..  So I don't see the advantage of ..

You mention the type assertion syntax, but that vague similarity seems
like another minor drawback, since this syntax would be used for
instantiation, which is nothing like type assertion.

Just my personal opinion, of course.

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

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

[Kevin Gillette]

On Wednesday, July 15, 2020 at 6:41:51 AM UTC-6 Michal Strba wrote:

> What about using a dot when specializing in bodies?
>
> func main() {
> x := zero.() // requires a dot
> }
>

What are all the kinds of "generic expressions" we would need to support? 
Go allows incomplete floating point literals (such as `x := 3.`)... Could 
angle brackets ever appear on the right side of such a floating point 
literal to mean something generic? If so, it would be ambiguous with a 
less-than comparison.

-- 
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/c94e7926-47c8-4530-9b37-70066a1be72dn%40googlegroups.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 12:26 PM Geoff Speicher  wrote:
>
> On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor  wrote:
>>
>> On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher  wrote:
>> >
>> > This is great work but compared to the rest of Go's existing syntax, I 
>> > personally find it much harder to grok the generic code examples 
>> > regardless of bracket choice.
>> >
>> > It seems like a lot of complication stems from what effectively amounts to 
>> > requiring the programmer to declare a new generic type everyplace one is 
>> > needed. This seems like a lot of unnecessary noise, especially when you 
>> > consider that a package is likely to reuse generic types.
>> > [clip]
>>
>> This seems similar to the discussion at
>> https://groups.google.com/d/msg/golang-nuts/mXn9x01mFzM/Zf7lSXVuBgAJ .
>>
>> It seems hard to know how to instantiate a generic function or type,
>> as there is no clear information in the declaration as to the presence
>> or order of the type parameters.
>
>
> I see. Is the problem here theoretically limited to the scenarios where type 
> inference does not work in the current design?

Yes, the problem I mentioned only arises in cases where type inference fails.

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

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

[Geoff Speicher]

On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor  wrote:

> On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher  wrote:
> >
> > This is great work but compared to the rest of Go's existing syntax, I
> personally find it much harder to grok the generic code examples regardless
> of bracket choice.
> >
> > It seems like a lot of complication stems from what effectively amounts
> to requiring the programmer to declare a new generic type everyplace one is
> needed. This seems like a lot of unnecessary noise, especially when you
> consider that a package is likely to reuse generic types.
> > [clip]
>
> This seems similar to the discussion at
> https://groups.google.com/d/msg/golang-nuts/mXn9x01mFzM/Zf7lSXVuBgAJ .
>
> It seems hard to know how to instantiate a generic function or type,
> as there is no clear information in the declaration as to the presence
> or order of the type parameters.
>

I see. Is the problem here theoretically limited to the scenarios where
type inference does not work in the current design?

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

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher  wrote:
>
> This is great work but compared to the rest of Go's existing syntax, I 
> personally find it much harder to grok the generic code examples regardless 
> of bracket choice.
>
> It seems like a lot of complication stems from what effectively amounts to 
> requiring the programmer to declare a new generic type everyplace one is 
> needed. This seems like a lot of unnecessary noise, especially when you 
> consider that a package is likely to reuse generic types.
>
> What if we were to require (or at least allow/encourage) declaration of any 
> generic types at the package level? Then any function or type is itself 
> generic by virtue of whether or not it uses any generic types.
>
> So instead of:
>
> // existing proposal requires additional (type T)
> // syntax for type parameter declaration
> func Print(type T)(s []T) {
> for _, v := range s {
> fmt.Println(v)
> }
> }
>
> We would have:
>
> // declare a new package-level type, similar to "type T" but using
> // a new keyword to indicate that it is generic
> generic T
>
> // Print is a generic function because T is a generic type
> func Print(s []T) {
> for _, v := range s {
> fmt.Println(v)
> }
> }
>
> The keyword generic indicates a generic type declaration, and since the Print 
> function uses the generic type T, we know that Print is a generic function. 
> We don't need any additional syntax at the site of the function definition. 
> Type constraints can appear within the type declaration just as they do in 
> the existing proposal's "inline" generic declaration.
>
> By encouraging reuse of the generic declaration, this approach also 
> encourages better choice of generic type naming instead of the ubiquitous T 
> which is used almost exclusively for its brevity in inline generic type 
> parameter declarations. For example:
>
> // declare a generic type with constraint of Stringer.
> // the name "Stringable" conveys more meaning than "T".
> generic Stringable Stringer
>
> // type definition requires no extra syntax for a generic type 
> parameter
> type StringableVector []Stringable
>
> // method definition requires no extra syntax for a generic type 
> parameter
> func (s StringableVector) String() string {
> var sb strings.Builder
> for i, v := range s {
> if i > 0 {
> sb.WriteString(", ")
> }
> // It's OK to call v.String here because v is of 
> generic type Stringable
> // and Stringable's constraint is Stringer.
> sb.WriteString(v.String())
> }
> return sb.String()
> }
>
> I don't know how this affects your implementation, but it certainly reduces 
> the need for many parser changes, and eliminates the need for extra brackets 
> in favor of a new keyword. It's also much easier for my aging eyes to read. ;)


This seems similar to the discussion at
https://groups.google.com/d/msg/golang-nuts/mXn9x01mFzM/Zf7lSXVuBgAJ .

It seems hard to know how to instantiate a generic function or type,
as there is no clear information in the declaration as to the presence
or order of the type parameters.

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/CAOyqgcV%2B%2BdQu%3DXo4G5owBFbYddRN1hSmwyr4LsF9mJOfVsFaiw%40mail.gmail.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 9:41 AM Rei Roldan  wrote:
>
> I agree, I prefer the D syntax as well.
>
> type!T Point struct {
> x, y int
> data !T
> }
>
> type Transformer interface {
> Transform(!R) !S
> }
>
> func Stringify(s []!T) string {
> }
>
> type Vector []!T
>
> Easy and readable :)

Hmmm, I didn't realize that the declarations and uses were different
in D.  I think it is a good feature of the current design draft that
we use the same sort of syntax at a declaration (func Stringify(type
T)) as at a use (Stringify(int)).

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU9PWRG0b9J9cDBRncv5qF93_5bVeY8jik1vwPFK%3DHa3w%40mail.gmail.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 7:22 AM christoph...@gmail.com
 wrote:
>
> I would like to insist on considering the D syntax using the ! for generics 
> instantiation.
>
> The first time I saw it, I was puzzled and found it unpleasant. But this is 
> just because it is unfamiliar and not intuitive.
> Once I got used to it, I found it much simple than the C++ templates. In fact 
> I even found it easier to use than the C++ notation.
>
> The thing is that generic instantiation will be very frequent and most of the 
> time with only one template argument. The notation using a simple ! is then 
> much lighter and readable then a notation using parenthesis.
>
> Please, consider and favor the readability and code lightness of the most 
> frequent use with generics which is the instantiation with one type argument.
>
> Compare T!int  with T(int)  or T[int] or T, or A!B!int with A(B(int)) or 
> A[B[int]] or A>.
>
> Please take the time time to experiment it and optimize the most frequent use.
> The D notation gave me the impression that use of generics was simple. Much 
> simpler than with C++.
>
> Go generics made a huge and good simplification by dropping the contracts. 
> Please, follow the same strategy for the instantiation of generics which will 
> be the most frequent occurrence in the code.

Honestly I find A(B(int)) or A[B[int]] to be clearer than A!B!int.  I
don't think A!B!int is horrible.  I just don't think it is the best
possible choice.  Of course that is just my personal opinion.

The sources for the experimental translation tool are available, so
anybody can try the experiment you suggest.  Even easier would be to
rewrite the examples using the D notation, to see how they look.

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%3Dy_ZH25JfvWvqN12VHhR6Lb7heqYvPhK2LzCtcwbaaA%40mail.gmail.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 1:23 AM Xie Zhenye  wrote:
>
> Requiring type-information for parsing will brings difficulty for 
> implementing these tools, but not impossible. To solve ambiguity, the only 
> requiring type-information is wether a symbol is a type name or an 
> identifier. A parser package can help this.Since other languages like Java, 
> C#, TypeScript can solve this, it must be a way for Go.

I'm going to try to be very clear.

Being able to parse Go without type information is a fundamental
design decision of the language, made when the project started back in
2007 (before I joined the project myself).

We are not going to change that decision.  If the only way that we can
add generics to Go is to require type information when parsing, then
we will not add generics to Go.

Fortunately the issue does not arise, as there are reasonable syntaxes
that we can use for generics that do not require type information when
parsing.

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

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

[Xie Zhenye]

Requiring type-information for parsing will brings difficulty for 
implementing these tools, but not impossible. To solve ambiguity, the only 
requiring type-information is wether a symbol is a type name or an 
identifier. A parser package can help this.Since other languages like Java, 
C#, TypeScript can solve this, it must be a way for Go. 

On Monday, July 20, 2020 at 2:43:53 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye  wrote:
>
>> Gramma of a programming language is not able to be changed after 
>> released. So language design is elegant or not is more important than 
>> difficulty of implementing. 
>>
>> Adding type information in parse time and use angle brackets only affects 
>> compiler and 3rd part tools or IDEs in a short time.
>>
>
> No, it creates lasting downsides. While programming, the normal state of a 
> program is to be broken in some way. And a tool that requires 
> type-information thus can only work on a correctly typed program. So, 
> requiring type-information for parsing will ultimately make many tools less 
> useful by a *lot*. Think about goimports for example - it *inherently* only 
> is used when full type-info is not available, by its very nature.
>
> In general, I really dislike these arguments, that it's just 
> implementation complexity and thus doesn't matter. Humans need to parse the 
> language as well, to read and write it.  And they'll have exactly the same 
> problems. A simple grammar doesn't just simplify things for parser-authors, 
> it also is vital for the people actually using the language.
>  
>
>> Providing parser tools and packages can help 3rd part tools/IDE to 
>> support new gramma. And for professional IDE provider, process generic go 
>> code will not be more difficult than other language like Java, TypeScript 
>> etc.
>>
>> On Wednesday, July 15, 2020 at 6:29:30 AM UTC+8 gri wrote:
>>
>>> 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])

 

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

['Axel Wagner' via golang-nuts]

On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye  wrote:

> Gramma of a programming language is not able to be changed after released.
> So language design is elegant or not is more important than difficulty of
> implementing.
>
> Adding type information in parse time and use angle brackets only affects
> compiler and 3rd part tools or IDEs in a short time.
>

No, it creates lasting downsides. While programming, the normal state of a
program is to be broken in some way. And a tool that requires
type-information thus can only work on a correctly typed program. So,
requiring type-information for parsing will ultimately make many tools less
useful by a *lot*. Think about goimports for example - it *inherently* only
is used when full type-info is not available, by its very nature.

In general, I really dislike these arguments, that it's just implementation
complexity and thus doesn't matter. Humans need to parse the language as
well, to read and write it.  And they'll have exactly the same problems. A
simple grammar doesn't just simplify things for parser-authors, it also is
vital for the people actually using the language.


> Providing parser tools and packages can help 3rd part tools/IDE to support
> new gramma. And for professional IDE provider, process generic go code will
> not be more difficult than other language like Java, TypeScript etc.
>
> On Wednesday, July 15, 2020 at 6:29:30 AM UTC+8 gri wrote:
>
>> 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 

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

[Viktor Kojouharov]

None of my laptops have guillamets on them, so that's pretty much dead on 
arrival

On Friday, July 17, 2020 at 5:56:32 PM UTC+2, Jon Conradt wrote:
>
> In the spirit of “show me, don’t tell me” and experience reports. How hard 
> would it be to release a beta which supports both [] and guillamets? We try 
> them. We see where we have compatibility problems. We give editor writers 
> and plugin writers a chance to simplify they keystrokes?
>
> Jon
>
> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>
>> 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/e93960b7-e62d-410c-a8f4-8581726067fdo%40googlegroups.com.

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

[Jon Conradt]

It is a serious suggestion. Our editors are flexible enough to allow us to use 
control keys to generate these characters. Our ethnocentric, ASCII limited view 
of programming languages would benefit from more flexibility when it increases 
readability.

Jon

Jon Conradt
——
j...@theconradts.com
Https://go.theconradts.com/patents


From: Yaw Boakye 
Sent: Saturday, July 18, 2020 10:43:11 AM
To: Jon Conradt 
Cc: golang-nuts 
Subject: Re: [go-nuts] Re: Generics and parentheses

I don't know if the recommendation to use guillamets is out of spite for the 
ongoing deliberations. But if it's a serious recommendation, then can some 
recommend where I can buy one of these European keyboards? On top of that, I 
could start a business selling European keyboards to Go programmers in Africa 
who want to use generics, where American keyboards (or keyboard with mostly 
ASCII characters) are common.

On Fri, Jul 17, 2020 at 4:56 PM Jon Conradt 
mailto:j...@theconradts.com>> wrote:
In the spirit of “show me, don’t tell me” and experience reports. How hard 
would it be to release a beta which supports both [] and guillamets? We try 
them. We see where we have compatibility problems. We give editor writers and 
plugin writers a chance to simplify they keystrokes?

Jon

On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
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<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com<https://groups.google.com/d/msgid/golang-nuts/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com?utm_medium=email_source=footer>.


--
Curried programmer
Homepage: http://yawboakye.com
I'm tweeting<https://twitter.com/@22bytes> when I'm not 
coding<https://github.com/yawboakye> when I'm not holding my niece.

-- 
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/MW3PR20MB3308FF96CE53CF63D9E6FE0EAC7D0%40MW3PR20MB3308.namprd20.prod.outlook.com.

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

[Steve Jones]

I'm glad that the use of ( and ) is being reconsidered as I found their use 
made *reading* source code with generics more difficult (albeit whilst 
making parsing easier). One of the features of Go I really like is how 
readable the source code is and every effort should be made to maintain 
this even at the expense of some extra typing (if a two character sequence 
is used). The observation that code is written once and read many times is 
(mostly) true.

On Saturday, 18 July 2020 at 15:44:04 UTC+1 wher...@gmail.com wrote:

> I don't know if the recommendation to use guillamets is out of spite for 
> the ongoing deliberations. But if it's a serious recommendation, then can 
> some recommend where I can buy one of these European keyboards? On top of 
> that, I could start a business selling European keyboards to Go programmers 
> in Africa who want to use generics, where American keyboards (or keyboard 
> with mostly ASCII characters) are common.
>
> On Fri, Jul 17, 2020 at 4:56 PM Jon Conradt  wrote:
>
>> In the spirit of “show me, don’t tell me” and experience reports. How 
>> hard would it be to release a beta which supports both [] and guillamets? 
>> We try them. We see where we have compatibility problems. We give editor 
>> writers and plugin writers a chance to simplify they keystrokes?
>>
>> Jon
>>
>> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>>
>>> 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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> *Curried programmer*
> *Homepage*: http://yawboakye.com
> I'm tweeting  when I'm not coding 
>  when I'm not holding my niece.
>

-- 
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/b7c4ebe7-a578-4fe4-a3c4-042accca5e14n%40googlegroups.com.

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

[Yaw Boakye]

I don't know if the recommendation to use guillamets is out of spite for
the ongoing deliberations. But if it's a serious recommendation, then can
some recommend where I can buy one of these European keyboards? On top of
that, I could start a business selling European keyboards to Go programmers
in Africa who want to use generics, where American keyboards (or keyboard
with mostly ASCII characters) are common.

On Fri, Jul 17, 2020 at 4:56 PM Jon Conradt  wrote:

> In the spirit of “show me, don’t tell me” and experience reports. How hard
> would it be to release a beta which supports both [] and guillamets? We try
> them. We see where we have compatibility problems. We give editor writers
> and plugin writers a chance to simplify they keystrokes?
>
> Jon
>
> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>
>> 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/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com
> 
> .
>


-- 
*Curried programmer*
*Homepage*: http://yawboakye.com
I'm tweeting  when I'm not coding
 when I'm not holding my niece.

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

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

[Jan Mercl]

On Sat, Jul 18, 2020 at 11:44 AM Mariusz Gronczewski  wrote:
> pipe character isn't exactly used anywhere in Go, is on every keyboard and 
> looks decent enough:

It's the bitwise binary or operator.

-- 
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-WDLMQWU%3DyHNW53wpHvVZskU5APNMmb%3DheRQPQ%3DcyGBHQ%40mail.gmail.com.

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

[Jan Mercl]

On Sat, Jul 18, 2020 at 7:22 AM Steve Ruble  wrote:

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

That requires an unbound lookahead which is better avoided.

-- 
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-VxTovCpDnRK_7ks-h1%3DQtBcLPQwGz9vNYXQ9OKuonLqA%40mail.gmail.com.

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

[Goodwine Carlos]

How would you deal if you use `-generics {` but your imported library uses 
`[`?

On Friday, July 17, 2020 at 3:56:39 PM UTC-7 rise...@gmail.com wrote:

> How about a "-generics" compile flag that lets you select one pair from a 
> character set of [ ( { < « .
>
> On Friday, July 17, 2020 at 8:56:32 AM UTC-7 Jon Conradt wrote:
>
>> In the spirit of “show me, don’t tell me” and experience reports. How 
>> hard would it be to release a beta which supports both [] and guillamets? 
>> We try them. We see where we have compatibility problems. We give editor 
>> writers and plugin writers a chance to simplify they keystrokes?
>>
>> Jon
>>
>> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>>
>>> 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/0fd7dda2-de54-4323-865a-7fab4e1b4972n%40googlegroups.com.

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

['Dan Kortschak' via golang-nuts]

On Fri, 2020-07-17 at 15:56 -0700, Jay Kay wrote:
> How about a "-generics" compile flag that lets you select one pair
> from a character set of [ ( { < « .

This hits two of the things that Go doesn't do:

   1. proliferation of compiler option flags
   2. enabling dialect spliting


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

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

[Jay Kay]

How about a "-generics" compile flag that lets you select one pair from a 
character set of [ ( { < « .

On Friday, July 17, 2020 at 8:56:32 AM UTC-7 Jon Conradt wrote:

> In the spirit of “show me, don’t tell me” and experience reports. How hard 
> would it be to release a beta which supports both [] and guillamets? We try 
> them. We see where we have compatibility problems. We give editor writers 
> and plugin writers a chance to simplify they keystrokes?
>
> Jon
>
> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>
>> 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/b34e70cc-de0e-4e40-bcd4-69229f61bd36n%40googlegroups.com.

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

[Patrick Kelly]

Perhaps many would think this is "too complicated" but I like the idea of 
supporting 2 syntaxes, one of which is the output of gofmt.

*func Print(type T)(s []T) * >> gofmt >> *func Print«T»(s []T)* 

This way nobody is required to type it right the first time, but everybody 
can read the code better (which is basically the job of gofmt, yes?)

I imagine that over time most go programmers would figure out a way to type 
« and », or it would get added into IDEs, etc.

On Tuesday, July 14, 2020 at 5:37:21 PM UTC-10 Ian Lance Taylor wrote:

> 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/0d17d532-e8eb-4ccb-ae49-6398c095a11cn%40googlegroups.com.

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

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 8:28 AM Dominique Devienne  wrote:
>
> On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote:
>>
>> Not unexpectedly, many people raised concerns about the syntax, specifically 
>> the choice of parentheses for type parameter declarations and generic type 
>> and function instantiations.
>
>
> Nobody mentioned D's generics? https://dlang.org/spec/template.html
>
> The exclamation mark meaning "instantiate" reads well IMHO,
> and the simpler single-type-parameter syntax omitting parens reads even 
> better,
> T!int is T instantiated (as in now, "at this instant"!) with int. FWIW, --DD

For the record, we did look at D's generics syntax.  It seems to work
syntactically, since ! is not a binary operator, but nobody was really
happy with how it looked on the page.  It's not a bad approach, it
just doesn't seem like the best choice at this time.

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

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

[Nathan Bosscher]

As others have mentioned, I'm still partial to angles to represent 
generics. e.g. func Method(input Type)
I'm really glad you didn't go the round bracket method as that's super 
confusing in a method declaration.
Squares aren't horrible, but I've always associated them with indexing/key 
lookups. I definitely wouldn't prefer it.

Looking forward to getting generics in Go!

Nate

On Friday, July 17, 2020 at 12:05:41 PM UTC-4 Michael Jones wrote:

> Jon, this is a special case where a "tr '«»' '[]'' is enough.
>
> On Fri, Jul 17, 2020 at 8:56 AM Jon Conradt  wrote:
>
>> In the spirit of “show me, don’t tell me” and experience reports. How 
>> hard would it be to release a beta which supports both [] and guillamets? 
>> We try them. We see where we have compatibility problems. We give editor 
>> writers and plugin writers a chance to simplify they keystrokes?
>>
>> Jon
>>
>> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>>
>>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
>
> *Michael T. jonesmichae...@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/17a3b4b8-35f0-45f8-a410-e205fca627b3n%40googlegroups.com.

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

[Michael Jones]

Jon, this is a special case where a "tr '«»' '[]'' is enough.

On Fri, Jul 17, 2020 at 8:56 AM Jon Conradt  wrote:

> In the spirit of “show me, don’t tell me” and experience reports. How hard
> would it be to release a beta which supports both [] and guillamets? We try
> them. We see where we have compatibility problems. We give editor writers
> and plugin writers a chance to simplify they keystrokes?
>
> Jon
>
> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>
>> 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/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@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/CALoEmQxooXkN0REjKy92h-4mhbirwfD4KKkZKg0Fas8NS5wWsw%40mail.gmail.com.

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

[Jon Conradt]

In the spirit of “show me, don’t tell me” and experience reports. How hard 
would it be to release a beta which supports both [] and guillamets? We try 
them. We see where we have compatibility problems. We give editor writers 
and plugin writers a chance to simplify they keystrokes?

Jon

On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:

> 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/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com.

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

[Mandolyte]

Since readability is impacted by consequitive lists, you could factor it out... 

with ( type list )
func ( arg list ) etc...

-- 
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/e06fc6ac-d4fe-433c-aacc-7e94b9352e77o%40googlegroups.com.

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

[Robert Engels]

Best proposal yet! I see increased Go adoption in the hipster /craft beer 
community. 

> On Jul 16, 2020, at 6:49 PM, Denis Cheremisov  
> wrote:
> 
> func XGenericFunction(x X) …
> 
> пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak: 
>> On Thu, 2020-07-16 at 13:44 -0700, jpap wrote: 
>> > Notwithstanding a concise unambiguous alternative, I would rather 
>> > type parameters "stick out" so they are easily identified when 
>> > visually scanning through code. 
>> 
>> func ᕙ(⇀ X ↼‶)ᕗ GenericFunction(x X) ... 
>> 
>> 
> 
> -- 
> 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/c44e256d-23df-4b11-a487-e221c684d886n%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/34959C93-8118-4FBE-ADE7-E049D61B1D95%40ix.netcom.com.

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

[Denis Cheremisov]

func XGenericFunction(x X) …

пятница, 17 июля 2020 г. в 01:25:29 UTC+3, kortschak: 

> On Thu, 2020-07-16 at 13:44 -0700, jpap wrote:
> > Notwithstanding a concise unambiguous alternative, I would rather
> > type parameters "stick out" so they are easily identified when
> > visually scanning through code.
>
> func ᕙ(⇀ X ↼‶)ᕗ GenericFunction(x X) ...
>
>
>

-- 
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/c44e256d-23df-4b11-a487-e221c684d886n%40googlegroups.com.

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

['Dan Kortschak' via golang-nuts]

On Thu, 2020-07-16 at 13:44 -0700, jpap wrote:
> Notwithstanding a concise unambiguous alternative, I would rather
> type parameters "stick out" so they are easily identified when
> visually scanning through code.

func ᕙ(⇀ X ↼‶)ᕗ GenericFunction(x X) ...


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

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

[Robert Viragh]

>I can accept draft as is

I've changed my mind about my suggestion.  I can also accept and fully
support draft as is!  It is fantastic.

On Fri, Jul 17, 2020 at 12:10 AM Matthias Mädel <
medienwerksalzb...@gmail.com> wrote:

> Just some considerations...
>
> Generics syntax is a constraint of the Parser
> Gen ops used with dB/ML/wire stuff...
> Encapsulating parantheses follow logic
> The type keyword shows the functionality
> square brackets introduce a, not only visual,
> distraction/confusion
>
> I can accept draft as is
>
> --
> 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/7t-Q2vt60J8/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/34a6b157-ba22-4ea1-9067-8548a67b9a7ao%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/CAFwChB%3DPteCW1iyH_3Mp2RTczo%3DkKen7dmgtvQx-YVjNtGci_w%40mail.gmail.com.

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

[Matthias Mädel]

Just some considerations...

Generics syntax is a constraint of the Parser 
Gen ops used with dB/ML/wire stuff...
Encapsulating parantheses follow logic 
The type keyword shows the functionality 
square brackets introduce a, not only visual,
distraction/confusion

I can accept draft as is

-- 
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/34a6b157-ba22-4ea1-9067-8548a67b9a7ao%40googlegroups.com.

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

[Robert Viragh]

On Thu, Jul 16, 2020 at 11:50 PM burak serdar  wrote:

>
> [_ _] is ambiguous though, because _ is also an identifier character.
> [_x_] can be parsed as indexing with identifier _x_
>

Yes, _int_ is an allowed identifier in Go.  However per the suggestion at
the top of the present thread the compiler already knows where [ and ]
signify a generic.  So if the user wants to use an identifier that begins
or ends with a _ then in those spots the user must include the _ rather
than have gofmt add it.  (Since gofmt would add a _ if there is no leading
or trailing _ at those spots but wouldn't add one if there is one.)

In other words if you want to use the identifier _x then you would end up
with [__x_], if you want to use the identifier x_ then you would end up
with [_x__] and if you want to use the identifier _x_ (which is allowed in
Go) you would write [__x__].

I think this is rare.  Keep them coming!  More corner cases?

-- 
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/CAFwChBmQ448PCq-sakg1X3GFtERu9SvdgGmU-E4ZwCMSoyLhoA%40mail.gmail.com.

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

[burak serdar]

On Thu, Jul 16, 2020 at 3:43 PM Robert Viragh  wrote:
>
> Hi guys,
>
> Great conversation! I think that seeing a lot of edge cases would make it 
> easiest to see what is best.
>
> Since the conversation went into [[ and ]]
>
> Before coming up with [_ and _] I very strongly considered [[ and ]] because 
> I thought things should be orthogonal and different things should look 
> different, not the same, and I thought that looked pretty different.

[_ _] is ambiguous though, because _ is also an identifier character.
[_x_] can be parsed as indexing with identifier _x_


>
> As I recall, I didn't like the look of it, and especially I didn't like that 
> it seemed to be nesting something.  However I did recall that python has """ 
> (triple quotation mark to start a multiline string) which is like a special 
> kind of quotation mark, yet consists of repeating the character, so I very 
> strongly considered [[ and ]] or even [[[ and ]]] as the right solution.  I 
> just didn't think it looked that great.
>
> However to me the few examples given so far look pretty good with [_ and _] 
> instead of [[ and ]].  Any more corner cases?  keep them coming!
>
> By jpap:
> > [[T]] -- https://go2goplay.golang.org/p/NXqVM89QFor
> > [T] -- https://go2goplay.golang.org/p/L9AKNHxPkUU
>
> Here it is with [_ and _] (doesn't run, obviously):
> https://go2goplay.golang.org/p/i3eZOeR-oD6
>
> I find this extremely readable, like crazy readable if you remember that [_ 
> _] is a mnemonic for fill in the blank.
>
> By Carla Pfaff:
>
> >MyMap[[string, MyList[[int
>
> Here it is with [_ and _]:
> MyMap[_string, MyList[_int_]_]
>
> that's really obvious to me if you consider that you're filling in the blank 
> - MyList is a generic and you're "filling the blank" in with int, and MyMap 
> is a generic and you're "filling the blank" in with string and MyList.  I 
> can't parse  MyMap[[string, MyList[[int with my eyes even if I know what 
> it's supposed to mean - I can't even see if the brackets are matched or 
> unmatched, can you?
>
> Could people reply with more corner examples?  I think a large wealth of 
> cases would best show the different options.
>
> The team came up with a really clever way to let [ and ] itself be 
> unambiguous (this whole thread, starting at the top), so I do think making it 
> more explicit (turning those [ and ] into [_ and _] at the appropriate spots) 
> could just be handled by gofmt.  This would make the gofmt'ed output very 
> readable forever and the user could still just enter [ and ] at the keyboard.
>
> Is there some collection of edge cases?  Can people come up with some more?
>
> I think we should see how it looks especially at the corners and more cases 
> and examples would show that best.
>
> --
> 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/CAFwChBn71m9%2B-DMTG5yH3g5TadKscm1X0WBwQKpzXyegxVN1PQ%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/CAMV2Rqp%3DkikN6kEDugQys66UCKNdWjUqHYX9_0QsBu1BKw2OXA%40mail.gmail.com.

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

[Robert Viragh]

Hi guys,

Great conversation! I think that seeing a lot of edge cases would make it
easiest to see what is best.

*Since the conversation went into [[ and ]]*

Before coming up with [_ and _] I very strongly considered [[ and ]]
because I thought things should be orthogonal and different things should
look different, not the same, and I thought that looked pretty different.

As I recall, I didn't like the look of it, and especially I didn't like
that it seemed to be nesting something.  However I did recall that python
has """ (triple quotation mark to start a multiline string) which is like a
special kind of quotation mark, yet consists of repeating the character, so
I very strongly considered [[ and ]] or even [[[ and ]]] as the right
solution.  I just didn't think it looked that great.

However to me the few examples given so far look pretty good with [_ and _]
instead of [[ and ]].  Any more corner cases?  keep them coming!

By jpap:
> [[T]] -- https://go2goplay.golang.org/p/NXqVM89QFor
> [T] -- https://go2goplay.golang.org/p/L9AKNHxPkUU

Here it is with [_ and _] (doesn't run, obviously):
https://go2goplay.golang.org/p/i3eZOeR-oD6

I find this extremely readable, like crazy readable if you remember that [_
_] is a mnemonic for fill in the blank.

By Carla Pfaff:

>MyMap[[string, MyList[[int

Here it is with [_ and _]:
MyMap[_string, MyList[_int_]_]

that's really obvious to me if you consider that you're filling in the
blank - MyList is a generic and you're "filling the blank" in with int, and
MyMap is a generic and you're "filling the blank" in with string and
MyList.  I can't parse  MyMap[[string, MyList[[int with my eyes even if
I know what it's supposed to mean - I can't even see if the brackets are
matched or unmatched, can you?

Could people reply with more corner examples?  I think a large wealth of
cases would best show the different options.

The team came up with a really clever way to let [ and ] itself be
unambiguous (this whole thread, starting at the top), so I do think making
it more explicit (turning those [ and ] into [_ and _] at the appropriate
spots) could just be handled by gofmt.  This would make the gofmt'ed output
very readable forever and the user could still just enter [ and ] at the
keyboard.

Is there some collection of edge cases?  Can people come up with some more?

I think we should see how it looks especially at the corners and more cases
and examples would show that best.

-- 
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/CAFwChBn71m9%2B-DMTG5yH3g5TadKscm1X0WBwQKpzXyegxVN1PQ%40mail.gmail.com.

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

['Carla Pfaff' via golang-nuts]

On Thursday, 16 July 2020 at 22:44:21 UTC+2 jpap wrote:

> I don't think [[T]] is offensive to the surrounding code, and would love 
> to know what more people think.
>

It becomes even worse once you nest generic types:

MyMap[[string, MyList[[int
 

-- 
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/e3a55215-7f51-4a51-b6f4-6861fc0b5e40n%40googlegroups.com.

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

[jpap]

Notwithstanding a concise unambiguous alternative, I would rather type 
parameters "stick out" so they are easily identified when visually scanning 
through code.  I read a lot more code than I write, even as I write Go 
full-time.

Here are two playgrounds (that don't format/run) comparing a generic hash 
table implementation using [[T]] vs. [T], based on a code sample by Matt 
Layher 
. 
 I don't think [[T]] is offensive to the surrounding code, and would love 
to know what more people think.  I'm happy to see generics progressing in 
Go and can't wait to use it either way.

[[T]] -- https://go2goplay.golang.org/p/NXqVM89QFor
[T] -- https://go2goplay.golang.org/p/L9AKNHxPkUU

jpap

On Thursday, 16 July 2020 at 13:19:10 UTC-7 Carla Pfaff wrote:

> Generics are not the most important part of the language/code. Let's not 
> make them stick out like a sore thumb.
> On Thursday, 16 July 2020 at 22:12:17 UTC+2 jpap wrote:
>
>> On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote:
>>
>>> On Thu, Jul 16, 2020 at 12:41 PM joshua harr  wrote: 
>>> > Just a note on your rationale for why not to use <: :> : 
>>> > "... requires more typing." Golang has, rather famously, never shied 
>>> away from making developers type more. The reason it hasn't, as far as I 
>>> understand, is that code is read far often than it is written, and so the 
>>> extra verbosity is worth the ease in reading the code. IMHO, that principle 
>>> very much applies here. The *readability* of the syntax should be a far 
>>> more important consideration than whether there is an extra character in 
>>> the syntax. 
>>>
>>> That's a fair point. Having two characters is still in my mind a 
>>> disadvantage, but I agree that that disadvantage could be outweighed 
>>> by a gain in readability. 
>>>
>>> That said, personally I don't find <:T:> to be any more (or less) 
>>> readable than [T]. 
>>>
>>> Ian 
>>>
>>
>> I agree that readability should be a big consideration.
>>
>> The problem with [T] is that you need to actively read the surrounding 
>> code to discern between a possible array access or type parameter.  I would 
>> prefer it to be immediately obvious so that visually scanning through code 
>> is as fast and clear as can be.
>>
>> An alternative syntax to [T] that could enable "quick looks" is [[T]]. 
>>  It would be nice to use <>, but that has parsing ambiguities with the 
>> existing bit-shift operator, just as  is ambiguous with the comparison 
>> operator.
>>
>> The burden of typing the same character twice on a keyboard in quick 
>> succession for [[T]] is more or less the same as the single-character 
>> version [T] and less so than two-character delimiters like <: and :>, and 
>> especially those delimiters that require the shift-key in play at the same 
>> time.
>>
>> jpap
>>
>>

-- 
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/987b9cc1-e35c-4a5f-a25d-61c21c4bdd91n%40googlegroups.com.

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

['Carla Pfaff' via golang-nuts]

Generics are not the most important part of the language/code. Let's not 
make them stick out like a sore thumb.
On Thursday, 16 July 2020 at 22:12:17 UTC+2 jpap wrote:

> On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote:
>
>> On Thu, Jul 16, 2020 at 12:41 PM joshua harr  wrote: 
>> > Just a note on your rationale for why not to use <: :> : 
>> > "... requires more typing." Golang has, rather famously, never shied 
>> away from making developers type more. The reason it hasn't, as far as I 
>> understand, is that code is read far often than it is written, and so the 
>> extra verbosity is worth the ease in reading the code. IMHO, that principle 
>> very much applies here. The *readability* of the syntax should be a far 
>> more important consideration than whether there is an extra character in 
>> the syntax. 
>>
>> That's a fair point. Having two characters is still in my mind a 
>> disadvantage, but I agree that that disadvantage could be outweighed 
>> by a gain in readability. 
>>
>> That said, personally I don't find <:T:> to be any more (or less) 
>> readable than [T]. 
>>
>> Ian 
>>
>
> I agree that readability should be a big consideration.
>
> The problem with [T] is that you need to actively read the surrounding 
> code to discern between a possible array access or type parameter.  I would 
> prefer it to be immediately obvious so that visually scanning through code 
> is as fast and clear as can be.
>
> An alternative syntax to [T] that could enable "quick looks" is [[T]].  It 
> would be nice to use <>, but that has parsing ambiguities with the 
> existing bit-shift operator, just as  is ambiguous with the comparison 
> operator.
>
> The burden of typing the same character twice on a keyboard in quick 
> succession for [[T]] is more or less the same as the single-character 
> version [T] and less so than two-character delimiters like <: and :>, and 
> especially those delimiters that require the shift-key in play at the same 
> time.
>
> jpap
>
>

-- 
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/8f7562b2-0262-4c3b-8659-d86bc7bba0dan%40googlegroups.com.

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

[jpap]

On Thursday, 16 July 2020 at 12:51:03 UTC-7 Ian Lance Taylor wrote:

> On Thu, Jul 16, 2020 at 12:41 PM joshua harr  wrote: 
> > Just a note on your rationale for why not to use <: :> : 
> > "... requires more typing." Golang has, rather famously, never shied 
> away from making developers type more. The reason it hasn't, as far as I 
> understand, is that code is read far often than it is written, and so the 
> extra verbosity is worth the ease in reading the code. IMHO, that principle 
> very much applies here. The *readability* of the syntax should be a far 
> more important consideration than whether there is an extra character in 
> the syntax. 
>
> That's a fair point. Having two characters is still in my mind a 
> disadvantage, but I agree that that disadvantage could be outweighed 
> by a gain in readability. 
>
> That said, personally I don't find <:T:> to be any more (or less) 
> readable than [T]. 
>
> Ian 
>

I agree that readability should be a big consideration.

The problem with [T] is that you need to actively read the surrounding code 
to discern between a possible array access or type parameter.  I would 
prefer it to be immediately obvious so that visually scanning through code 
is as fast and clear as can be.

An alternative syntax to [T] that could enable "quick looks" is [[T]].  It 
would be nice to use <>, but that has parsing ambiguities with the 
existing bit-shift operator, just as  is ambiguous with the comparison 
operator.

The burden of typing the same character twice on a keyboard in quick 
succession for [[T]] is more or less the same as the single-character 
version [T] and less so than two-character delimiters like <: and :>, and 
especially those delimiters that require the shift-key in play at the same 
time.

jpap

-- 
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/74bd82c9-c612-43c5-a263-0adcf739372cn%40googlegroups.com.

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

[Ahmed Mones]

Why not have a github emoji vote.

1. () `type MyMap(K comparable, V something) struct { m map[k]v }; fn(int,
float)(4, .20);`
2. [] `type MyMap[K comparable, V something] struct { m map[k]v }; fn[int,
float](4, .20);`
3. <::> `type MyMap<:K comparable, V something:> struct { m map[k]v };
fn<:int,float:>(4, .20);`
4. ::<> `type MyMap:: struct { m map[k]v };
fn::(4, .20);`
5..8 ... other viable suggestions

That way the community would be able to easily vote and give the developers
a better idea,
because a lot of people don't even use the mailing list.




On Thu, Jul 16, 2020 at 2:51 PM Ian Lance Taylor  wrote:

> On Thu, Jul 16, 2020 at 12:41 PM joshua harr 
> wrote:
> >
> > Just a note on your rationale for why not to use <: :> :
> > "... requires more typing." Golang has, rather famously, never shied
> away from making developers type more. The reason it hasn't, as far as I
> understand, is that code is read far often than it is written, and so the
> extra verbosity is worth the ease in reading the code. IMHO, that principle
> very much applies here. The *readability* of the syntax should be a far
> more important consideration than whether there is an extra character in
> the syntax.
>
> That's a fair point.  Having two characters is still in my mind a
> disadvantage, but I agree that that disadvantage could be outweighed
> by a gain in readability.
>
> That said, personally I don't find <:T:> to be any more (or less)
> readable than [T].
>
> Ian
>
>
>
> > On Wednesday, July 15, 2020 at 12:14:31 AM UTC-4 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/985c8685-484c-417c-a421-fe7a222d56c7n%40googlegroups.com
> .
>
> --
> 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/7t-Q2vt60J8/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/CAOyqgcUu0Jh%3DCsQ-0zy%3DkY3uFesYPBUAovYbvUyvPxpW%2BpPEiw%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/CANi8n3D_jY9Jm5Et9mzFgOoMLQHP3ZaLoTi85r%3DpG80-zaffXQ%40mail.gmail.com.

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

[Ian Lance Taylor]

On Thu, Jul 16, 2020 at 12:41 PM joshua harr  wrote:
>
> Just a note on your rationale for why not to use <: :> :
> "... requires more typing." Golang has, rather famously, never shied away 
> from making developers type more. The reason it hasn't, as far as I 
> understand, is that code is read far often than it is written, and so the 
> extra verbosity is worth the ease in reading the code. IMHO, that principle 
> very much applies here. The *readability* of the syntax should be a far more 
> important consideration than whether there is an extra character in the 
> syntax.

That's a fair point.  Having two characters is still in my mind a
disadvantage, but I agree that that disadvantage could be outweighed
by a gain in readability.

That said, personally I don't find <:T:> to be any more (or less)
readable than [T].

Ian



> On Wednesday, July 15, 2020 at 12:14:31 AM UTC-4 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/985c8685-484c-417c-a421-fe7a222d56c7n%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/CAOyqgcUu0Jh%3DCsQ-0zy%3DkY3uFesYPBUAovYbvUyvPxpW%2BpPEiw%40mail.gmail.com.

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

[joshua harr]

Just a note on your rationale for why not to use <: :> :
"... requires more typing." Golang has, rather famously, never shied away 
from making developers type more. The reason it hasn't, as far as I 
understand, is that code is read far often than it is written, and so the 
extra verbosity is worth the ease in reading the code. IMHO, that principle 
very much applies here. The *readability* of the syntax should be a far 
more important consideration than whether there is an extra character in 
the syntax.

On Wednesday, July 15, 2020 at 12:14:31 AM UTC-4 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/985c8685-484c-417c-a421-fe7a222d56c7n%40googlegroups.com.

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

[gcf]

Its worth noting that Rust does something similar with the "turbofish" 
operator in expressions:

"42".parse::()

I personally think this works quite well.

On Wednesday, July 15, 2020 at 5:41:51 AM UTC-7, Michal Strba wrote:
>
> Angle brackets are only problematic in expressions in the bodies of 
> functions when specializing a function or a type, right? They are not 
> problematic in signatures and type definitions.
>
> What about using a dot when specializing in bodies?
>
> func zero() T {
> var z T
> return z
> }
>
> func main() {
> x := zero.() // requires a dot
> }
>
> This is less weird than it looks, because Go already uses a dot for type 
> assertions and this is a similar thing.
>

-- 
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/e7d2b4f6-b11d-47e0-b7cd-19b38d9b06d3o%40googlegroups.com.

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

[Ian Lance Taylor]

On Wed, Jul 15, 2020 at 7:59 AM kaleidawave  wrote:
>
> Correct me if I am wrong but wouldn't square bracket syntax have an ambiguity 
> around calling a function pointer at a position in a slice:
>
> z := []func() int{x, y};
> a := z[0]();

A parsing ambiguity arises when the same code can be parsed in
different ways.  This case isn't an ambiguity, because it is always
parsed as "z[0]" followed by "()".  It's true that until type checking
we don't know whether "z[0]" is an index expression or a function
instantiation.  But that is OK.  We have similar issues in the
language today for "f(x)", which could be either a function call or a
type conversion.

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

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

[Ian Lance Taylor]

On Wed, Jul 15, 2020 at 7:59 AM jpap  wrote:
>
> Two thoughts:
>
> 1. How useful is it in practice to have separate start and end delimiters?  
> Does it matter for nested declarations?  I didn't see any nested declarations 
> in the Draft Design document, for example.  If allow the same token on both 
> sides, we could use the vertical bar, and not require the type keyword at all:
>
> func f(T|int|)
>
> struct{ T|int| }
>
> interface{ T|int| }
>
> []T|int|{}
>
> type S|T| struct { v T }

I think that vertical bars will have some of the same problems as
angle brackets, since the vertical bar is itself an operator in Go.

a, b = w | x, y | (z)

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

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

[Yaw Boakye]

I'm in favor of the square brackets. scala has them as well so we're not
exactly blazing a new trail. I'm not in favor of a second `type` keyword
whose benefit is to disambiguate syntax to the parser. we already use
significant whitespace to identify tokens. for example, we expect to be
parsing a function after we've parsed the `func\s+`. I'll take a parsing
error over repeated the type keyword. In this regard we're not along
either. Erlang's less-than-or-equals operator is =<. It inadvertently makes
whitespace a requirement when doing binary syntax: `X = <<"hello">>`.
Without the significant whitespace after the equals sign, the Erlang parser
always finds the `=<` operator, which leads to a parsing error. A similar
behavior for the square brackets syntax will be desirable.

On Wed 15 Jul 2020 at 09:32 Max  wrote:

> I think square brackets are better than parentheses for several reasons:
>
> 1. fewer parser ambiguities (see the post that started this thread) - thus
> fewer cases where programmers must remember "oh, this is a special case, I
> must put additional parentheses somewhere"
> 2. programmers can distinguish more easily between a template
> instantiation `T1[T2]` and a function call `T1(T2)`. Index expressions
> would have the same syntax as single-type template instantiations `T1[T2]`,
> but I believe they are somewhat less common than function calls in most code
> 3. Go already uses a similar syntax for builtin types: `map[K]V`. A
> generic key/value container would look like `Map[K, V]` which is pretty
> close
>
> In my Go interpreter, I went a step further and implemented the syntax
> `T1#[T2, T3]` for generics instantiation. It may not be everybody's
> favorite, but removes all parsing ambiguities.
>
> An alternative syntax, more similar to other proposals I have seen, is
> `T1:[T2, T3]` - it could be visually better, but I think it introduces
> ambiguities in `case` and labels marking `goto` destinations - both already
> use ':' as delimiter.
>
> On Wednesday, July 15, 2020 at 6:14:31 AM UTC+2, Ian Lance Taylor wrote:
>>
>>
>> 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/1e8397a5-bcc9-48b8-924b-1d35f4434d14o%40googlegroups.com
> 
> .
>
-- 
*Curried programmer*
*Homepage*: http://yawboakye.com
I'm tweeting  when I'm not coding
 when I'm not holding my niece.

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

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

[janerikkeller]

Go code use a Syntax analog to casting instead of the type keyword.

f.[int](args)
or
var x map[string]GType.[int]

That does not collide with other language features in function declaration, 
type definitions, inner types in structs or interfaces, variable declarations, 
type alias declarations and maps / array / chan type declarations.

-- 
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/7b761b3b-4e72-4e59-8aab-54b3d2649cf7o%40googlegroups.com.

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

[David Riley]

On Jul 15, 2020, at 12:13 AM, Ian Lance Taylor  wrote:
> 
> 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.

Not to mention that, while Go *is* officially in UTF-8, the chance of an output 
device or editor mis-formatting something that isn't 7-bit ASCII is still 
reasonably significant even in 2020, and that has much graver consequences for 
delimiters than for, say, identifiers or string contents.  I'm curious about 
how screen readers react as well; I know we have one or two folks on this list 
who could probably offer some perspective there.

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

I think square brackets do the job of visually disambiguating the syntax from 
the other uses of parentheses on the same lines well enough, and it sounds like 
with the "type" keyword they do the job well enough for the parser as well.  
Personally, I have no horse in the race for square vs. angle brackets (other 
than I think it would be foolish to do something technically infeasible or 
problematic just because it subjectively looks nicer), but then, I also like 
Objective-C's visual styling, so YMMV.


- 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/94FC42B1-ABD0-4E37-AE80-0B4313DC34C9%40gmail.com.

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

[Michal Strba]

Angle brackets are only problematic in expressions in the bodies of
functions when specializing a function or a type, right? They are not
problematic in signatures and type definitions.

What about using a dot when specializing in bodies?

func zero() T {
var z T
return z
}

func main() {
x := zero.() // requires a dot
}

This is less weird than it looks, because Go already uses a dot for type
assertions and this is a similar thing.

On Wed, 15 Jul 2020 at 05:39 Ian Lance Taylor  wrote:

> 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/CAO6k0uuAqy2kgvEWYL%2BRxhMgjW7rQi8pCaORuaauSWjmb_Mq%2BA%40mail.gmail.com.

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

[Max]

I think square brackets are better than parentheses for several reasons:

1. fewer parser ambiguities (see the post that started this thread) - thus 
fewer cases where programmers must remember "oh, this is a special case, I 
must put additional parentheses somewhere"
2. programmers can distinguish more easily between a template instantiation 
`T1[T2]` and a function call `T1(T2)`. Index expressions would have the 
same syntax as single-type template instantiations `T1[T2]`, but I believe 
they are somewhat less common than function calls in most code
3. Go already uses a similar syntax for builtin types: `map[K]V`. A generic 
key/value container would look like `Map[K, V]` which is pretty close

In my Go interpreter, I went a step further and implemented the syntax 
`T1#[T2, T3]` for generics instantiation. It may not be everybody's 
favorite, but removes all parsing ambiguities.

An alternative syntax, more similar to other proposals I have seen, is 
`T1:[T2, T3]` - it could be visually better, but I think it introduces 
ambiguities in `case` and labels marking `goto` destinations - both already 
use ':' as delimiter.

On Wednesday, July 15, 2020 at 6:14:31 AM UTC+2, Ian Lance Taylor wrote:
>
>
> 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/1e8397a5-bcc9-48b8-924b-1d35f4434d14o%40googlegroups.com.

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

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.