Re: [go-nuts] Generics and parentheses

[Frederik Zipp]

jlge...@gmail.com schrieb am Montag, 17. August 2020 um 19:13:45 UTC+2:

>
>- No support covariance or contravariance. Maybe I am on shaky ground 
>in terms of my understanding but doesn't this mean, for instance, that if 
> I 
>have two interfaces, Foo and Bar, and a third composite interface, FooBar, 
>which consists of Foo and Bar, that a function with a generic parameter T 
>constrained by Foo would not accept a type that implements FooBar? If i am 
>incorrect, where does this come into play?
>
> What you describe does work: https://go2goplay.golang.org/p/5bLN7fDMVGN

2) I don't see syntax for directly applying multiple constraints to a 
> generic type. Is this achievable only via interface composition? 
>

Yes, and it can be inlined as usual:

func Example[T interface{Foo; Bar}](s []T) {
}

Although naming complex types is a good idea. 

-- 
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/d4cce9ed-f84c-415c-946d-73c9a63eebfen%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

On Mon, Aug 17, 2020 at 10:13 AM Jonathan Gerber  wrote:
>
> 1) Of the enumerated omissions, the ones that I think are really unfortunate 
> are, in order of importance, from my perspective:
>
> No operator methods & no adapters - Doesn't this make generic types sort of 
> second class?. I think these features would be an elegant addition to the 
> language but I assume that there is a reason for their omission.

To me this is kind of separate from generics.  It's true that the lack
of operator methods means that user defined types are never as capable
as the types predefined by the language.  But that limitation seems to
apply to all types, not just generic types.


> No support covariance or contravariance. Maybe I am on shaky ground in terms 
> of my understanding but doesn't this mean, for instance, that if I have two 
> interfaces, Foo and Bar, and a third composite interface, FooBar, which 
> consists of Foo and Bar, that a function with a generic parameter T 
> constrained by Foo would not accept a type that implements FooBar? If i am 
> incorrect, where does this come into play?

Go in general does not support covariance and contravariance because
those are complex concepts and Go has a very simple type system.
https://golang.org/doc/faq#covariant_types .  That said, I don't think
that your example uses covariance.  If FooBar is composed of Foo and
Bar (type FooBar interface { Foo; Bar }) then any type that implements
FooBar also implements Foo.


> No support for variadic type parameters. Rust gets around this with hygienic 
> macros and meta-programming. I am not a big fan of the level of 
> complexity/quirkiness involved with working around the lack of variadics in 
> Rust. I hope to see them in Generics in Go one day. Otherwise, you will 
> probably end up api bloat full of functions differing only in the number of 
> parameters supported.

We may get variadic type parameters some day, if we can figure out a
way to make them work.  I don't think that's a priority for the first
version, though.  And it's not easy to see how to make them work;
their support in C++ seems to rely heavily on SFINAE, which I don't
think we particularly we want in Go.

> 2) I don't see syntax for directly applying multiple constraints to a generic 
> type. Is this achievable only via interface composition?

Yes.


> 3) And something I glossed over during the first reading, but is a bit sad - 
> Methods may not take additional type arguments.

Yes.  I think we'd all like them if we can figure out how to implement
them, but it's not obvious.  See the example at
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods
.


> Also, in the area of ergonomics, here are some thoughts:
> 1) Allow for separating out generic type declarations from constraints. Rust 
> allows you to split type parameter declaration from type constraints via an 
> optional `where` keyword which comes right before the body of the entity. 
> This is very helpful for readability, especially given complex constraints.

The current design draft lets you move complex constraints into their
own separately defined type, so I don't see a clear need for further
separation.

> 2) I personally don't think allowing multiple types to share a constraint is 
> worth not allowing unbounded types without the bulky "interface{}" type. Is 
> there some other simpler syntax that could be considered? Would a simple {} 
> be a parsing nightmare? What about '_' ?  Something like `func Something 
> (type T _, U SuperUseful ) (a T, b U){...}` ?

Most likely we would support using "any" as an alias for "interface{}".

Thanks for the note.

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/CAOyqgcXjHwq%3Dep0uD%2BYvntLmETfJFEJ9MytJrW7Egvs5tkT2mw%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Beka Westberg]

> No support covariance or contravariance. Maybe I am on shaky ground in 
terms of my understanding but doesn't this mean, for instance, that if I 
have two interfaces, Foo and Bar, and a third composite interface, FooBar, 
which consists of Foo and Bar, that a function with a generic parameter T 
constrained by Foo would not accept a type that implements FooBar? If i am 
incorrect, where does this come into play?

I've actually be doing some reading on this lately! I'd love a chance to 
try and explain it to someone.

So covariance / contravariance has to do with subtyping and parameterized 
types. If a type T' is a subtype of T that means that T' fulfills the 
responsibilities of T and can be used anywhere T is used. Subtyping for 
parameterized types gets more tricky. For example []int is not a subtype of 
[]interface{} (even though int is a subtype of interface{}), because you 
cannot use a []int anywhere you use a []interface{}. The important case 
being: you cannot add an interface{} to a []int, but you can add an 
interface{} to a []interface{}. The only subtype of []interface{} is 
[]interface{}.

So covariance is where a parameter to a parameterized type *can* accept 
subtypes. For example an immutable list would be covariant. 
ImmutableList(int) fulfills the responsibilities ImmutableList(interface{}).

Contravariance is where a parameter to a parameterized type can only accept 
*super*types. For example functions are contravariant with respect to their 
input parameters. A Function(i interface{}) fulfills the responsibilities 
of Function(i int)

Invariance is where a parameter to a parameterized type only accepts the 
specific type specified. As stated above slices are invariant.

So my understanding is that in the current design doc all generic structs 
would be treated as invariant wrt their parameters (like slices) even if 
they could technically be treated as covariant or contravariant wrt their 
parameters without causing errors.

I hope that helps!
--Beka


On Monday, August 17, 2020 at 10:13:45 AM UTC-7 jlge...@gmail.com wrote:

> As someone who has spent a LOT of time in Rust, I really miss generics in 
> Go (Conversely, i miss the simplicity of Go. My personal favorite, 
> imaginary language would probably be  Go + Generics + Sum Types and 
> destructuring) and so I am really excited to see this taking shape. 
>
> That being said, here are some things that I personally think are less 
> than ideal (first world problems eh?):
>
> 1) Of the enumerated omissions, the ones that I think are really 
> unfortunate are, in order of importance, from my perspective: 
>
>- No operator methods & no adapters - Doesn't this make generic types 
>sort of second class?. I think these features would be an elegant addition 
>to the language but I assume that there is a reason for their omission. 
>- No support covariance or contravariance. Maybe I am on shaky ground 
>in terms of my understanding but doesn't this mean, for instance, that if 
> I 
>have two interfaces, Foo and Bar, and a third composite interface, FooBar, 
>which consists of Foo and Bar, that a function with a generic parameter T 
>constrained by Foo would not accept a type that implements FooBar? If i am 
>incorrect, where does this come into play?
>- No support for variadic type parameters. Rust gets around this with 
>hygienic macros and meta-programming. I am not a big fan of the level of 
>complexity/quirkiness involved with working around the lack of variadics 
> in 
>Rust. I hope to see them in Generics in Go one day. Otherwise, you will 
>probably end up api bloat full of functions differing only in the number 
> of 
>parameters supported.
>
> 2) I don't see syntax for directly applying multiple constraints to a 
> generic type. Is this achievable only via interface composition? 
> 3) And something I glossed over during the first reading, but is a bit sad 
> - Methods may not take additional type arguments. 
>
> Also, in the area of ergonomics, here are some thoughts:
> 1) Allow for separating out generic type declarations from constraints. 
> Rust allows you to split type parameter declaration from type constraints 
> via an optional `where` keyword which comes right before the body of the 
> entity. This is very helpful for readability, especially given complex 
> constraints.
> 2) I personally don't think allowing multiple types to share a constraint 
> is worth not allowing unbounded types without the bulky "interface{}" type. 
> Is there some other simpler syntax that could be considered? Would a simple 
> {} be a parsing nightmare? What about '_' ?  Something like `func Something 
> (type T _, U SuperUseful ) (a T, b U){...}` ?
> On Monday, August 10, 2020 at 9:46:44 AM UTC-7 3cl...@gmail.com wrote:
>
>> I am trying to add my 2 cents here.
>>
>>
>> I am sorry if my opinions have been mentioned.
>>
>> I personally prefer Round Brackets (parentheses). It is not about 

Re: [go-nuts] Generics and parentheses

[Jonathan Gerber]

As someone who has spent a LOT of time in Rust, I really miss generics in 
Go (Conversely, i miss the simplicity of Go. My personal favorite, 
imaginary language would probably be  Go + Generics + Sum Types and 
destructuring) and so I am really excited to see this taking shape. 

That being said, here are some things that I personally think are less than 
ideal (first world problems eh?):

1) Of the enumerated omissions, the ones that I think are really 
unfortunate are, in order of importance, from my perspective: 

   - No operator methods & no adapters - Doesn't this make generic types 
   sort of second class?. I think these features would be an elegant addition 
   to the language but I assume that there is a reason for their omission. 
   - No support covariance or contravariance. Maybe I am on shaky ground in 
   terms of my understanding but doesn't this mean, for instance, that if I 
   have two interfaces, Foo and Bar, and a third composite interface, FooBar, 
   which consists of Foo and Bar, that a function with a generic parameter T 
   constrained by Foo would not accept a type that implements FooBar? If i am 
   incorrect, where does this come into play?
   - No support for variadic type parameters. Rust gets around this with 
   hygienic macros and meta-programming. I am not a big fan of the level of 
   complexity/quirkiness involved with working around the lack of variadics in 
   Rust. I hope to see them in Generics in Go one day. Otherwise, you will 
   probably end up api bloat full of functions differing only in the number of 
   parameters supported.

2) I don't see syntax for directly applying multiple constraints to a 
generic type. Is this achievable only via interface composition? 
3) And something I glossed over during the first reading, but is a bit sad 
- Methods may not take additional type arguments. 

Also, in the area of ergonomics, here are some thoughts:
1) Allow for separating out generic type declarations from constraints. 
Rust allows you to split type parameter declaration from type constraints 
via an optional `where` keyword which comes right before the body of the 
entity. This is very helpful for readability, especially given complex 
constraints.
2) I personally don't think allowing multiple types to share a constraint 
is worth not allowing unbounded types without the bulky "interface{}" type. 
Is there some other simpler syntax that could be considered? Would a simple 
{} be a parsing nightmare? What about '_' ?  Something like `func Something 
(type T _, U SuperUseful ) (a T, b U){...}` ?
On Monday, August 10, 2020 at 9:46:44 AM UTC-7 3cl...@gmail.com wrote:

> I am trying to add my 2 cents here.
>
>
> I am sorry if my opinions have been mentioned.
>
> I personally prefer Round Brackets (parentheses). It is not about 
> readability on symbols, but the way how I understand the logic of Type 
> Parameters.
>
>
>
> I see Type Parameters as a way to describe how to "instantiated" a 
> Declaration (Func/Struct) for being used.
>
> Considering the case of https://go2goplay.golang.org/p/JjA67w8ZvFu , the 
> func `min` is asking for a `type` argument to be specified so it can work 
> properly. Which means it is valid to code line L19 `m := min(int)` to 
> initialize the func `min` with type `int`. 
>
> If we try to read a Type Parameterized func declared in this way, it means 
> the func `min` will first take a `type` argument to initialize it. then the 
> second Round Brackets `(...)` put the arguments to call the func. 
>
> However with Square Bracket, L19 of the case will not work, cause `m := 
> min[int]` would mean taking an element from `min` on index `int`. (sure, 
> min here is a Type Parameterized Func, not a slice)
>
>
>
> On the other hand, we can take an analogy of how Functional Programming 
> (FP) works with funcs with multi parameters. (correct me if I am wrong). 
>
> In FP, when a function take two arguments, say `f(a int, b string)`, it's 
> actually interpreted as "A function called `f`, it will first take an 
> argument `a` with type `int`, and return a function f2 which keep a copy of 
> `a` and takes an argument `b` with type `string`". 
>
> An example in Go is following:
>
> ```go
> func concat(a int, b string) string {}
> ```
>
> is equal to
>
> ```go
> func concat(a int) (func( b string) string){
> return func(b string) {
> a := a
> // DO THE ACTUAL WORK
> return
> }
> }
> 
> and when calling `concat()` with `concat(1, "2")`, is actually 
> `concat(1)(2)` or `tmp := concat(1); result := tmp(2)`
>
>
> Taking this analogy back to the original Type Parameters proposal. We can 
> think of a Type Parameterized func has to be called with a `type` being 
> specified. The Type Parameterized func will return a typed version of it. 
> Then we call it with the actual argument(s). 
>
> With Square Brackets, it cannot be interpreted in this way IMO as the 
> syntax is inconsistence. It only make it easier to read for 

Re: [go-nuts] Generics and parentheses

[Edwin S]

I am trying to add my 2 cents here.


I am sorry if my opinions have been mentioned.

I personally prefer Round Brackets (parentheses). It is not about 
readability on symbols, but the way how I understand the logic of Type 
Parameters.



I see Type Parameters as a way to describe how to "instantiated" a 
Declaration (Func/Struct) for being used.

Considering the case of https://go2goplay.golang.org/p/JjA67w8ZvFu , the 
func `min` is asking for a `type` argument to be specified so it can work 
properly. Which means it is valid to code line L19 `m := min(int)` to 
initialize the func `min` with type `int`. 

If we try to read a Type Parameterized func declared in this way, it means 
the func `min` will first take a `type` argument to initialize it. then the 
second Round Brackets `(...)` put the arguments to call the func. 

However with Square Bracket, L19 of the case will not work, cause `m := 
min[int]` would mean taking an element from `min` on index `int`. (sure, 
min here is a Type Parameterized Func, not a slice)



On the other hand, we can take an analogy of how Functional Programming 
(FP) works with funcs with multi parameters. (correct me if I am wrong). 

In FP, when a function take two arguments, say `f(a int, b string)`, it's 
actually interpreted as "A function called `f`, it will first take an 
argument `a` with type `int`, and return a function f2 which keep a copy of 
`a` and takes an argument `b` with type `string`". 

An example in Go is following:

```go
func concat(a int, b string) string {}
```

is equal to

```go
func concat(a int) (func( b string) string){
return func(b string) {
a := a
// DO THE ACTUAL WORK
return
}
}

and when calling `concat()` with `concat(1, "2")`, is actually 
`concat(1)(2)` or `tmp := concat(1); result := tmp(2)`


Taking this analogy back to the original Type Parameters proposal. We can 
think of a Type Parameterized func has to be called with a `type` being 
specified. The Type Parameterized func will return a typed version of it. 
Then we call it with the actual argument(s). 

With Square Brackets, it cannot be interpreted in this way IMO as the 
syntax is inconsistence. It only make it easier to read for declaring a 
Type Parameterized func, but not easier to make an instance of the func 
with type.


On Saturday, August 8, 2020 at 12:02:51 PM UTC+2 Denis Cheremisov wrote:

> > Have the authors considered the implications of requiring the `type` 
> keyword to use a generic type, not just at declaration time? Would this 
> open up more syntax possibilities, such as `var x T`? This might 
> be easier to read at the expense of five more characters of typing. It also 
> could unify declaration and usage syntax even more than the proposal.
>
> > This might be easier to read
>
> Square brackets are easier to read. They are larger and catchier to eyes 
> than lesser and greater signs used as brackets. And type-less syntax with 
> mandatory constraint is even easier and feels like a great match with the 
> rest of the language.
>
>
> четверг, 6 августа 2020 г. в 22:25:19 UTC+3, Red Daly: 
>
>> Have the authors considered the implications of requiring the `type` 
>> keyword to use a generic type, not just at declaration time? Would this 
>> open up more syntax possibilities, such as `var x T`? This might 
>> be easier to read at the expense of five more characters of typing. It also 
>> could unify declaration and usage syntax even more than the proposal.
>>
>> (Personally, I will accept any syntax. It's not realistic to expect this 
>> for go2, but I would prefer if go3 ditched the C-style syntax altogether in 
>> favor of a simpler, lisp-style syntax. Such a syntax would make it easier 
>> to introduce language features like this one. Macros and metaprogramming 
>> would also be much more straightforward for users to add useful 
>> abstractions to the language.)
>> On Thursday, August 6, 2020 at 7:15:08 AM UTC-7 Mike Schinkel wrote:
>>
>>> Hi Russ,
>>>
>>> In general, I think the proposal is a really good one.  I like that you 
>>> abandoned contracts as interfaces were just too similar, and personally I 
>>> like the choice of square brackets.
>>>
>>> There are a few aspects I do not like — 1.) no zero value and 2.) lack 
>>> of covariance and contravariance — but perhaps those can be addressed in 
>>> the future?
>>>
>>> All in all, I think the team has come up with a really good approach to 
>>> generics, much better than the prior proposals.
>>>
>>> -Mike
>>>
>>> P.S. If there is one thing that piqued my interest about this thread it 
>>> was Geoff Speicher's suggestion of a "generic" keyword, assuming type 
>>> inference could be addressed. That approach would be even easier to reason 
>>> about than the current proposal, I think.  That said, the current proposal 
>>> is very good if type inference can not be addressed in Geoff Speicher's 
>>> suggestion.
>>>
>>> On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox 

Re: [go-nuts] Generics and parentheses

[Denis Cheremisov]

> Have the authors considered the implications of requiring the `type` 
keyword to use a generic type, not just at declaration time? Would this 
open up more syntax possibilities, such as `var x T`? This might 
be easier to read at the expense of five more characters of typing. It also 
could unify declaration and usage syntax even more than the proposal.

> This might be easier to read

Square brackets are easier to read. They are larger and catchier to eyes 
than lesser and greater signs used as brackets. And type-less syntax with 
mandatory constraint is even easier and feels like a great match with the 
rest of the language.


четверг, 6 августа 2020 г. в 22:25:19 UTC+3, Red Daly: 

> Have the authors considered the implications of requiring the `type` 
> keyword to use a generic type, not just at declaration time? Would this 
> open up more syntax possibilities, such as `var x T`? This might 
> be easier to read at the expense of five more characters of typing. It also 
> could unify declaration and usage syntax even more than the proposal.
>
> (Personally, I will accept any syntax. It's not realistic to expect this 
> for go2, but I would prefer if go3 ditched the C-style syntax altogether in 
> favor of a simpler, lisp-style syntax. Such a syntax would make it easier 
> to introduce language features like this one. Macros and metaprogramming 
> would also be much more straightforward for users to add useful 
> abstractions to the language.)
> On Thursday, August 6, 2020 at 7:15:08 AM UTC-7 Mike Schinkel wrote:
>
>> Hi Russ,
>>
>> In general, I think the proposal is a really good one.  I like that you 
>> abandoned contracts as interfaces were just too similar, and personally I 
>> like the choice of square brackets.
>>
>> There are a few aspects I do not like — 1.) no zero value and 2.) lack of 
>> covariance and contravariance — but perhaps those can be addressed in the 
>> future?
>>
>> All in all, I think the team has come up with a really good approach to 
>> generics, much better than the prior proposals.
>>
>> -Mike
>>
>> P.S. If there is one thing that piqued my interest about this thread it 
>> was Geoff Speicher's suggestion of a "generic" keyword, assuming type 
>> inference could be addressed. That approach would be even easier to reason 
>> about than the current proposal, I think.  That said, the current proposal 
>> is very good if type inference can not be addressed in Geoff Speicher's 
>> suggestion.
>>
>> On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox wrote:
>>
>>> So it sounds like everyone is in favor of the entire generics proposal 
>>> and all the semantics, and all we have left to hammer out is the bracket 
>>> characters? Do I have that right?
>>>
>>> Best,
>>> Russ
>>>
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fbc7a998-0e8d-46ff-a59a-23a63a8a5aa0n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

['Axel Wagner' via golang-nuts]

On Thu, Aug 6, 2020 at 9:26 PM 'Red Daly' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Have the authors considered the implications of requiring the `type`
> keyword to use a generic type, not just at declaration time? Would this
> open up more syntax possibilities, such as `var x T`? This might
> be easier to read at the expense of five more characters of typing. It also
> could unify declaration and usage syntax even more than the proposal.
>
If we take the goal of unifying both syntaxes to the extreme, we shouldn't
have type-inference; after all, writing `Stringify[type Foo]([]Foo{})` is
far closer to the declaration syntax than `Stringify([]Foo{})`.
Personally, while I agree that at some level, unifying the two syntactical
constructs is valuable, but it shouldn't be taken to extremes. IMO, the
type keyword at instantiation doesn't pull enough weight to justify the
additional effort.


> (Personally, I will accept any syntax. It's not realistic to expect this
> for go2, but I would prefer if go3 ditched the C-style syntax altogether in
> favor of a simpler, lisp-style syntax. Such a syntax would make it easier
> to introduce language features like this one. Macros and metaprogramming
> would also be much more straightforward for users to add useful
> abstractions to the language.)
> On Thursday, August 6, 2020 at 7:15:08 AM UTC-7 Mike Schinkel wrote:
>
>> Hi Russ,
>>
>> In general, I think the proposal is a really good one.  I like that you
>> abandoned contracts as interfaces were just too similar, and personally I
>> like the choice of square brackets.
>>
>> There are a few aspects I do not like — 1.) no zero value and 2.) lack of
>> covariance and contravariance — but perhaps those can be addressed in the
>> future?
>>
>> All in all, I think the team has come up with a really good approach to
>> generics, much better than the prior proposals.
>>
>> -Mike
>>
>> P.S. If there is one thing that piqued my interest about this thread it
>> was Geoff Speicher's suggestion of a "generic" keyword, assuming type
>> inference could be addressed. That approach would be even easier to reason
>> about than the current proposal, I think.  That said, the current proposal
>> is very good if type inference can not be addressed in Geoff Speicher's
>> suggestion.
>>
>> On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox wrote:
>>
>>> So it sounds like everyone is in favor of the entire generics proposal
>>> and all the semantics, and all we have left to hammer out is the bracket
>>> characters? Do I have that right?
>>>
>>> Best,
>>> Russ
>>>
>>>
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/99722814-e4eb-45cd-8d18-ff75905e5c47n%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/CAEkBMfGP7y_msYkch3kDUfTv0xf%2BWJQQD5zS19tBncTstR%2BsDQ%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

On Thu, Aug 6, 2020 at 12:25 PM 'Red Daly' via golang-nuts
 wrote:
>
> Have the authors considered the implications of requiring the `type` keyword 
> to use a generic type, not just at declaration time? Would this open up more 
> syntax possibilities, such as `var x T`? This might be easier to 
> read at the expense of five more characters of typing. It also could unify 
> declaration and usage syntax even more than the proposal.

Well, no, I don't think we ever considered that approach.

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/CAOyqgcXXohj7ne1evSY%2B%2Bx-MnQL504vrrS%3DfCGN5B686-p0kug%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

['Red Daly' via golang-nuts]

Have the authors considered the implications of requiring the `type` 
keyword to use a generic type, not just at declaration time? Would this 
open up more syntax possibilities, such as `var x T`? This might 
be easier to read at the expense of five more characters of typing. It also 
could unify declaration and usage syntax even more than the proposal.

(Personally, I will accept any syntax. It's not realistic to expect this 
for go2, but I would prefer if go3 ditched the C-style syntax altogether in 
favor of a simpler, lisp-style syntax. Such a syntax would make it easier 
to introduce language features like this one. Macros and metaprogramming 
would also be much more straightforward for users to add useful 
abstractions to the language.)
On Thursday, August 6, 2020 at 7:15:08 AM UTC-7 Mike Schinkel wrote:

> Hi Russ,
>
> In general, I think the proposal is a really good one.  I like that you 
> abandoned contracts as interfaces were just too similar, and personally I 
> like the choice of square brackets.
>
> There are a few aspects I do not like — 1.) no zero value and 2.) lack of 
> covariance and contravariance — but perhaps those can be addressed in the 
> future?
>
> All in all, I think the team has come up with a really good approach to 
> generics, much better than the prior proposals.
>
> -Mike
>
> P.S. If there is one thing that piqued my interest about this thread it 
> was Geoff Speicher's suggestion of a "generic" keyword, assuming type 
> inference could be addressed. That approach would be even easier to reason 
> about than the current proposal, I think.  That said, the current proposal 
> is very good if type inference can not be addressed in Geoff Speicher's 
> suggestion.
>
> On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox wrote:
>
>> So it sounds like everyone is in favor of the entire generics proposal 
>> and all the semantics, and all we have left to hammer out is the bracket 
>> characters? Do I have that right?
>>
>> Best,
>> Russ
>>
>>
>>
>>

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

Re: [go-nuts] Generics and parentheses

[Mike Schinkel]

Hi Russ,

In general, I think the proposal is a really good one.  I like that you 
abandoned contracts as interfaces were just too similar, and personally I 
like the choice of square brackets.

There are a few aspects I do not like — 1.) no zero value and 2.) lack of 
covariance and contravariance — but perhaps those can be addressed in the 
future?

All in all, I think the team has come up with a really good approach to 
generics, much better than the prior proposals.

-Mike

P.S. If there is one thing that piqued my interest about this thread it 
was Geoff Speicher's suggestion of a "generic" keyword, assuming type 
inference could be addressed. That approach would be even easier to reason 
about than the current proposal, I think.  That said, the current proposal 
is very good if type inference can not be addressed in Geoff Speicher's 
suggestion.

On Wednesday, July 22, 2020 at 8:02:55 PM UTC-4 Russ Cox wrote:

> So it sounds like everyone is in favor of the entire generics proposal and 
> all the semantics, and all we have left to hammer out is the bracket 
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/56865922-75d0-43c6-8a4e-6777c39fce25n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Steven Blenkinsop]

On Wed, Jul 22, 2020 at 8:02 PM, Russ Cox  wrote:

> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>

I think this thread is specifically about the delimiters (first post is
about using square brackets instead of parentheses), but yeah, seems about
right.

I sort of wish interfaces allowed you to specify a receiver type rather
than requiring reflexive application (even where supported by syntax
sugar). Essentially:

type CustomOrdered interface(R) {
Less(other R) bool
}

instead of

type CustomOrdered[type T] interface {
Less(other T) bool
}

However, this is similar to type lists in interfaces in that it would make
the interface only usable as a constraint, since otherwise the receiver
type isn't known at compile time. The current design sidesteps this by
requiring you to specify a specific type argument in order to use the
interface as a type, even if the resulting interface type isn't terribly
useful. Reflexive application only works when using the interface as a
constraint.

>

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

Re: [go-nuts] Generics and parentheses

[Kent Sandvik]

[ ] is nice. Nim also uses [ ] for generics. --Kent

On Wed, Jul 22, 2020 at 4:41 PM Denis Cheremisov 
wrote:

> Lesser and greater signs never were a good choice. They were chosen
> because of C syntax restrictions. Go creators would do *slice[T]* (or may
> be just *[T]*), *map[K,V]*,* chan[T]*, etc if they had generics in mind.
> Because, if you have managed not to notice it, Go barely inherited anything
> from C. Know why? Because C is full of unfortunate decisions. Some people
> love it because this is their first relatively low level language and they
> like the power. Me, who wrote assembler before C, have never been impressed
> with it: its syntax is not particularly pleasant to read and I rather felt
> the lack of power with it. It is not only hard to read, it is just plain
> weird. Consider this:
>
> a * b;
>
> What is this? May be an expression? Or a declaration, pointer a of type b?
>
> So, please stop using languages with syntax inherited from C as a
> benchmark. The C is a result of the lack of planning, a chaotic
> development. And this usage of comparison operators as brackets is an
> unfortunate combination of circumstances.
> Luckily, there was a planning in Go, with some initial limitations which
> causes a bit of pain nowdays, still much better than C and even more so
> than C++. I am really glad they don't consider these < monstrosities: I
> tried Scala and as much as I dislike the language in general their []
> things for generic parameters left very good impression. I really like they
> borrowed the idea.
>
> четверг, 23 июля 2020 г. в 00:22:26 UTC+3, sah...@naman.ms:
>
>> With angled brackets, do we really need the colon or dot on both sides?
>> Wouldn't it be enough to just have it on the left to eliminate the parse
>> time ambiguities?  Like f<:int> or f<.int>?
>>
>> On Wed, 22 Jul 2020, 22:46 Евгений Кошевой,  wrote:
>>
>>> Maybe something like this:
>>> using <.Type.>
>>> func f(T<.int.>)
>>> struct{ T<.int.> }
>>> interface{ T<.int.> }
>>> []T<.int.>{}
>>>
>>> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop:
>>>
 On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba 
 wrote:

> I'd say a dot is necessary when instantiating a function call but
> unnecessary when instantiating a type because it's always syntactically
> clear when a type is required.
>

 That's not true in Go. Conversions look like function calls:

   y := f(x)

 could be a conversion or a function call, depending on whether f is a
 function or a type. If you need to use type parameters on f, the same
 parsing problems present themselves whether it's a parameterized type or a
 type parametric function.

> --
>>> 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/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%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/f5e27f11-3dc4-4caa-adc4-4f4619a50cfcn%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/CAHC_roEWOD870YOVvXZ54r-CY4FP4n-UhQXiCVJ2UjL-%2B0ZL-g%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Michael Jones]

So it seems! nothing substantive on the hard part.

On Wed, Jul 22, 2020 at 5:02 PM Russ Cox  wrote:

> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA8EjDRrEBeOgs2Yax%2BgtHp-oJqCApjGJJEsop-S1OzOJbU3xA%40mail.gmail.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/CALoEmQyUQPGYKGLfVvdHLrvyPq4X2Vc5RLZcWSv6Kqm8hghZ6Q%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[David Riley]

On Jul 22, 2020, at 8:02 PM, Russ Cox  wrote:
> 
> So it sounds like everyone is in favor of the entire generics proposal and 
> all the semantics, and all we have left to hammer out is the bracket 
> characters? Do I have that right?

We haven't covered what the bike shed roof is going to be made from, but other 
than that, assuming things like type switches are planned to be solved in the 
end, I'm happy with it.


- 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/71B4F56E-471C-4AD3-9B24-7BF3BE136BCE%40gmail.com.

Re: [go-nuts] Generics and parentheses

[Michal Strba]

Very correct! At least from my perspective.

On Thu, 23 Jul 2020 at 02:02 Russ Cox  wrote:

> So it sounds like everyone is in favor of the entire generics proposal and
> all the semantics, and all we have left to hammer out is the bracket
> characters? Do I have that right?
>
> Best,
> Russ
>
>
>
> --
> 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/CAA8EjDRrEBeOgs2Yax%2BgtHp-oJqCApjGJJEsop-S1OzOJbU3xA%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/CAO6k0usy2JKtkKgtkfNeveLv9X%2B7YiO0mjHbna2o%2B5ef4%2BRBow%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[David Riley]

On Jul 15, 2020, at 4:59 PM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 15, 2020 at 5:44 AM Jan Mercl <0xj...@gmail.com> wrote:
>> 
>> My 2c - Alternative type parameters syntax (ab)using @$:
>> https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing
> 
> Thanks for the detailed writeup.  I'm a bit concerned about name
> scoping.  Also about the fact that constraints can apparently show up
> anywhere; is that always going to work?  And I don't think that
> Vector@$T is going to be all that intuitive for anybody to read.

Well, it should make the VMS programmers happier.


- 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/262C2302-3FA7-4A43-B535-C402D3BA7626%40gmail.com.

Re: [go-nuts] Generics and parentheses

[Russ Cox]

So it sounds like everyone is in favor of the entire generics proposal and
all the semantics, and all we have left to hammer out is the bracket
characters? Do I have that right?

Best,
Russ

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

Re: [go-nuts] Generics and parentheses

[Denis Cheremisov]

Lesser and greater signs never were a good choice. They were chosen because 
of C syntax restrictions. Go creators would do *slice[T]* (or may be just 
*[T]*), *map[K,V]*,* chan[T]*, etc if they had generics in mind. Because, 
if you have managed not to notice it, Go barely inherited anything from C. 
Know why? Because C is full of unfortunate decisions. Some people love it 
because this is their first relatively low level language and they like the 
power. Me, who wrote assembler before C, have never been impressed with it: 
its syntax is not particularly pleasant to read and I rather felt the lack 
of power with it. It is not only hard to read, it is just plain weird. 
Consider this:

a * b;

What is this? May be an expression? Or a declaration, pointer a of type b?

So, please stop using languages with syntax inherited from C as a 
benchmark. The C is a result of the lack of planning, a chaotic 
development. And this usage of comparison operators as brackets is an 
unfortunate combination of circumstances.
Luckily, there was a planning in Go, with some initial limitations which 
causes a bit of pain nowdays, still much better than C and even more so 
than C++. I am really glad they don't consider these < monstrosities: I 
tried Scala and as much as I dislike the language in general their [] 
things for generic parameters left very good impression. I really like they 
borrowed the idea.

четверг, 23 июля 2020 г. в 00:22:26 UTC+3, sah...@naman.ms: 

> With angled brackets, do we really need the colon or dot on both sides?  
> Wouldn't it be enough to just have it on the left to eliminate the parse 
> time ambiguities?  Like f<:int> or f<.int>?
>
> On Wed, 22 Jul 2020, 22:46 Евгений Кошевой,  wrote:
>
>> Maybe something like this:
>> using <.Type.>
>> func f(T<.int.>)
>> struct{ T<.int.> }
>> interface{ T<.int.> }
>> []T<.int.>{}
>>
>> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop: 
>>
>>> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  
>>> wrote:
>>>
 I'd say a dot is necessary when instantiating a function call but 
 unnecessary when instantiating a type because it's always syntactically 
 clear when a type is required.

>>>
>>> That's not true in Go. Conversions look like function calls:
>>>
>>>   y := f(x)
>>>
>>> could be a conversion or a function call, depending on whether f is a 
>>> function or a type. If you need to use type parameters on f, the same 
>>> parsing problems present themselves whether it's a parameterized type or a 
>>> type parametric function.
>>>
 -- 
>> 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/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%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/f5e27f11-3dc4-4caa-adc4-4f4619a50cfcn%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Sahas Subramanian]

With angled brackets, do we really need the colon or dot on both sides?
Wouldn't it be enough to just have it on the left to eliminate the parse
time ambiguities?  Like f<:int> or f<.int>?

On Wed, 22 Jul 2020, 22:46 Евгений Кошевой, 
wrote:

> Maybe something like this:
> using <.Type.>
> func f(T<.int.>)
> struct{ T<.int.> }
> interface{ T<.int.> }
> []T<.int.>{}
>
> среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop:
>
>> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  wrote:
>>
>>> I'd say a dot is necessary when instantiating a function call but
>>> unnecessary when instantiating a type because it's always syntactically
>>> clear when a type is required.
>>>
>>
>> That's not true in Go. Conversions look like function calls:
>>
>>   y := f(x)
>>
>> could be a conversion or a function call, depending on whether f is a
>> function or a type. If you need to use type parameters on f, the same
>> parsing problems present themselves whether it's a parameterized type or a
>> type parametric function.
>>
>>> --
> 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/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%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/CAJSNQU3cNoakwEhaAiSjur8Hgs%2BnoaMzEgk%2BVtG9TYKt8z2MEQ%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Евгений Кошевой]

Maybe something like this:
using <.Type.>
func f(T<.int.>)
struct{ T<.int.> }
interface{ T<.int.> }
[]T<.int.>{}

среда, 22 июля 2020 г. в 01:12:32 UTC+3, Steven Blenkinsop: 

> On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  wrote:
>
>> I'd say a dot is necessary when instantiating a function call but 
>> unnecessary when instantiating a type because it's always syntactically 
>> clear when a type is required.
>>
>
> That's not true in Go. Conversions look like function calls:
>
>   y := f(x)
>
> could be a conversion or a function call, depending on whether f is a 
> function or a type. If you need to use type parameters on f, the same 
> parsing problems present themselves whether it's a parameterized type or a 
> type parametric function.
>
>>

-- 
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/a6a400ee-b9e2-4f30-a82d-a39ad8f5aaafn%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Steven Blenkinsop]

On Tue, Jul 21, 2020 at 3:12 PM, Michal Strba  wrote:

> I'd say a dot is necessary when instantiating a function call but
> unnecessary when instantiating a type because it's always syntactically
> clear when a type is required.
>

That's not true in Go. Conversions look like function calls:

  y := f(x)

could be a conversion or a function call, depending on whether f is a
function or a type. If you need to use type parameters on f, the same
parsing problems present themselves whether it's a parameterized type or a
type parametric function.

>

-- 
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/CANjmGJsep6MaLPdGQ2KN6omtWp7Uv6sXC7%2BdpWSeQ2G9MMu-QA%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Michal Strba]

I'd say a dot is necessary when instantiating a function call but
unnecessary when instantiating a type because it's always syntactically
clear when a type is required.

ut 21. 7. 2020 o 18:51  napísal(a):

> Using angle brackets is not a must for supporting generics, but it is the
> common syntax of generics in programming languages that support generics,
> the same way as square brackets are the common syntax for indexing in
> programming languages.
>
> If I understand correctly, the ambiguity problem with angle brackets
> appears only at instantiation, so if we prefixed all the angle brackets
> occurrences with a dot(.) that ambiguity would gone.
>
> Although prefixing the angle brackets with a dot(.) in all occurrences is
> not required and maybe removed from some places and/or be required only for
> instantiation.
>
> The common use for the dot(.) in programming languages is to access some
> field or property of the entity it's called on, and that would be the
> same(in instantiation case), cause we would be accessing the specific
> function, or the specific type of the generic function or the generic type,
> respectively, so that common understanding about the dot(.) would still
> hold, in my opinion.
>
> If I understand correctly(and please correct me if I am wrong) the dot(.)
> in that approach doesn't introduce any ambiguity and would require only one
> lookahead(to see if the following char is the left angle bracket or not),
> so it should be acceptable.
>
> example:
>
> package list
>
> type List. struct {  // the dot(.) maybe remove here
> // some code
> }
>
> type FloatList List.  // the dot(.) has to exist here
>
> func NewList.() (list List.) {  // the dot(.) maybe remove here
> // some code
> }
>
> func NewListFrom.(arr []E) (list List.) {  // the dot(.) maybe
> remove here
> // some code
> }
>
> func(l List.) Add(newElem E) {  // the dot(.) maybe remove here
> // some code
> }
>
> package main
>
> func main() {
> l := list.NewList.()  // the dot(.) has to exist here
> l.Add(1)
> var arr []int
> intList := list.NewListFrom(arr) // type inference is done here,
> so the dot(.) doesn't exist here
> }
>
> --
> 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/0b206c05-e10c-48a4-b641-cb29209b9df5o%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/CAO6k0uu8hE2MmavFUjVZALkxPEYPTOr10Cp%3DYj6oE0%2BOt1GEQw%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[brettcaomail]

like java？i like it

在 2020年7月15日星期三 UTC+8上午6:31:55，Harald Weidner写道：
>
> Hello, 
>
> > A typical computer keyboard provides four easily accessible pairs of 
> > single-character symmetrical "brackets": parentheses ( and ), square 
> > brackets [ and ], curly braces { and }, and angle brackets < and >. Go 
> uses 
> > curly braces to delineate code blocks, composite literals, and some 
> > composite types, making it virtually impossible to use them for generics 
> > without severe syntactic problems. Angle brackets require unbounded 
> parser 
> > look-ahead or type information in certain situations (see the end of 
> this 
> > e-mail for an example). This leaves us with parentheses and square 
> > brackets. 
>
> Another option would be the introduction of a new two-letter 
> "bracket" operator, for example <: and :> . This could be parsed 
> without symbol/type information and even without the "type" keyword. 
>
> That said, I'm fine with any syntax. Thank you for your work on 
> generics! 
>
> Regards, 
> Harald 
>

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

Re: [go-nuts] Generics and parentheses

[ahmadelshehy]

Using angle brackets is not a must for supporting generics, but it is the 
common syntax of generics in programming languages that support generics, the 
same way as square brackets are the common syntax for indexing in programming 
languages.

If I understand correctly, the ambiguity problem with angle brackets appears 
only at instantiation, so if we prefixed all the angle brackets occurrences 
with a dot(.) that ambiguity would gone. 

Although prefixing the angle brackets with a dot(.) in all occurrences is not 
required and maybe removed from some places and/or be required only for 
instantiation. 

The common use for the dot(.) in programming languages is to access some field 
or property of the entity it's called on, and that would be the same(in 
instantiation case), cause we would be accessing the specific function, or the 
specific type of the generic function or the generic type, respectively, so 
that common understanding about the dot(.) would still hold, in my opinion. 

If I understand correctly(and please correct me if I am wrong) the dot(.) in 
that approach doesn't introduce any ambiguity and would require only one 
lookahead(to see if the following char is the left angle bracket or not), so it 
should be acceptable. 

example:

package list

type List. struct {  // the dot(.) maybe remove here
// some code
}

type FloatList List.  // the dot(.) has to exist here

func NewList.() (list List.) {  // the dot(.) maybe remove here
// some code
}

func NewListFrom.(arr []E) (list List.) {  // the dot(.) maybe remove here
// some code
}

func(l List.) Add(newElem E) {  // the dot(.) maybe remove here
// some code
}

package main

func main() {
l := list.NewList.()  // the dot(.) has to exist here
l.Add(1)
var arr []int
intList := list.NewListFrom(arr) // type inference is done here, so the 
dot(.) doesn't exist here
}

-- 
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/0b206c05-e10c-48a4-b641-cb29209b9df5o%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Peter McKenzie]

This seems to be very similar to a suggestion I made a couple of years ago: 
https://gist.github.com/peter-mckenzie/5cc6530da1d966e743f4a39c150a6ac2
The spaces are in different places but that could be regarded as a matter 
of style.

I always liked it, but maybe a little too quirky for most :-)

On Sunday, July 19, 2020 at 12:52:10 PM UTC+12, Laurens Hellemons wrote:
>
> The more I think about this suggestion, the more I like it. 
>
> - It solves the lookahead problem (I think);
> - it visually separates the type parameters from the actual parameters and 
> return types, so the choice of delimiter characters for the type arguments 
> becomes less relevant from a readability standpoint;
>
> it even makes sense *semantically*, since what you're defining with a 
> generic type/func is really *multiple* types/funcs (a family of related 
> ones), so it makes sense for the definition to look like an 
> array/list/vector.
>
> I haven't played with this style yet, so I'm not sure that it doesn't 
> present other drawbacks, but this is my favorite proposed syntax so far.
>
>
> On Wednesday, July 15, 2020 at 7:06:24 AM UTC+2 Paul Johnston wrote:
>
>> If the generic expression  was always attached/constrained to the 
>> "type" or "func" keyword (rather than the type or function name), perhaps 
>> this would decrease the lookahead problems with lexing?  For example:
>>
>> *type Point struct {*
>> *x, y int*
>> *data T*
>> *}*
>>
>> *type Transformer interface {*
>> *Transform(R) S*
>> *}*
>>
>> *func Stringify(s []T) string {*
>> *}*
>>
>> *type Vector []T*
>>
>>
>>
>> On Tuesday, July 14, 2020 at 10:45:41 PM UTC-6 ren...@ix.netcom.com 
>> wrote:
>>
>>> My opinion is that every major language (no flames please… lots of 
>>> developers write lots of programs and make money doing it) that supports 
>>> generics uses < > for generic types, so Go should too - since there is no 
>>> reason to deviate from this other than to avoid changes to the parser. 
>>> Seems better to pay this cost once - rather than every Go program that uses 
>>> generics being harder to read for eternity (especially for those readers 
>>> that use a lot of languages). 
>>>
>>> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  
>>> wrote: 
>>> > 
>>> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>>> wrote: 
>>> >> 
>>> >> This feels a little better, but honestly I'm still all for angle 
>>> brackets or like Watson suggested, guillamets. 
>>> >> 
>>> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 
>>> >> fn[T1](fn2[T2](fn3[T3](v))) // 2 
>>> >> fn(fn2(fn3(v))) // 3 
>>> >> fn«T1»(fn2«T2»(fn3«T3»v))) // 4 
>>> >> 
>>> >> To me, with a background in C++ and Typescript and a little bit of 
>>> Rust, #3 and #4 are just natural and easier to read. 
>>> > 
>>> > The advantage of parentheses is that the language already uses 
>>> > parentheses for lists in various places. Of course that is also the 
>>> > disadvantage. 
>>> > 
>>> > When considering something other than parentheses, I encourage people 
>>> > to look for objective reasons why one syntax is better than another. 
>>> > It's going to be different from other aspects of the language. So 
>>> > what reason would we have for preferring one syntax over another? 
>>> > 
>>> > For example: 
>>> > 
>>> > Robert already gave reasons why square brackets are better than angle 
>>> brackets. 
>>> > 
>>> > The disadvantage of guillemets is that they are hard to type on many 
>>> > keyboards. So to me either square brackets or angle brackets would be 
>>> > better than guillemets. 
>>> > 
>>> > The disadvantage of a two character sequence such as <: :> is that it 
>>> > is more typing. So again either square brackets or angle brackets 
>>> > seem to me to be better. 
>>> > 
>>> > An example of a reason that square brackets might be a poor choice 
>>> > would be ambiguous parsing, or cases where the code is harder to read. 
>>> > 
>>> > It's true that some other languages use angle brackets, but Go already 
>>> > does many things differently. That is only a minor advantage for 
>>> > angle brackets. To me at least it does not outweigh the 
>>> > disadvantages. 
>>> > 
>>> > In short, please try to provide reasons for a different syntax. "It 
>>> > looks good" is a valid reason, but please try to explain why it looks 
>>> > better than square brackets or parentheses. 
>>> > 
>>> > Thanks. 
>>> > 
>>> > Ian 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group. 
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com. 
>>> > To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX-OXktNtUs0G4Ns0iEr3R2qLPpU7q1%3DrOY93%3DAO16a3g%40mail.gmail.com.
>>>  
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails 

Re: [go-nuts] Generics and parentheses

[K Davidson]

Not that I am for guillemets, but isn't attempting to push the industry towards 
a richer pallette than ASCII the whole point of building unicode into the core 
of go? We already include the middot in go assembly, and some core members of 
the go team love using unicode identifiers in personal code ( ^_^ ). It's one 
of the frontier-pushing aspects that attracted me to go in the first place ( I 
enjoyed identifier rules in opendylan, which did not restrict symbols in 
identifiers, leading to much more expresiveness; like ! for mkmethods that are 
destructive with the data, such as `reset!`, or ? for boolean return values, 
like `iszero?`) Not to mention most of us already overload our keys nowdays 
anyways; I have yet to see a keyboard with a leader key ;]

-k

-- 
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/2387bc26-3221-47a1-9c98-e58ac319c9cdo%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Laurens Hellemons]

The more I think about this suggestion, the more I like it. 

- It solves the lookahead problem (I think);
- it visually separates the type parameters from the actual parameters and 
return types, so the choice of delimiter characters for the type arguments 
becomes less relevant from a readability standpoint;

it even makes sense *semantically*, since what you're defining with a 
generic type/func is really *multiple* types/funcs (a family of related 
ones), so it makes sense for the definition to look like an 
array/list/vector.

I haven't played with this style yet, so I'm not sure that it doesn't 
present other drawbacks, but this is my favorite proposed syntax so far.


On Wednesday, July 15, 2020 at 7:06:24 AM UTC+2 Paul Johnston wrote:

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

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

Re: [go-nuts] Generics and parentheses

[Jakob Borg]

I don't think there's any real risk of guillemets ever being adopted. But since 
this appears to be a serious proposal...

Even as a European programmer using a custom keyboard with programmable 
firmware and layout (so essentially the optimal target audience for the 
proposal) it seems cruel and unusual. I started learning Go almost ten years 
ago because I wanted to learn something new and looked at the various "new on 
the block" languages at that time. If Go had required a specific magic 
editor/config or unusual keyboard layout it would have been a hard pass. Having 
this as a requirement on new programmers seems absurd, I think.

//kb

On 18 Jul 2020, at 21:11, Jon Conradt 
mailto:j...@theconradts.com>> wrote:

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<mailto:j...@theconradts.com>
Https://go.theconradts.com/patents


From: Yaw Boakye mailto:wheres...@gmail.com>>
Sent: Saturday, July 18, 2020 10:43:11 AM
To: Jon Conradt mailto:j...@theconradts.com>>
Cc: golang-nuts 
mailto:golang-nuts@googlegroups.com>>
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<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<mailto: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<https://groups.google.com/d/msgid/golang-nuts/MW3PR20MB3308FF96CE53CF63D9E6FE0EAC7D0%40MW3PR20MB3308.namprd20.prod.outlook.com?utm_medium=email_source=footer>.

-- 
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/F6A41A04-BDBC-46C2-A8C9-0B8D19BF4DC5%40kastelo.net.

Re: [go-nuts] Generics and parentheses

[Kiswono Prayogo]

Older thread: 
https://groups.google.com/u/0/g/golang-nuts/c/zGQq_I5r2jg/m/_LPQDf3BBgAJ
And the poll: https://www.surveylegend.com/s/2dwe
On Saturday, July 18, 2020 at 11:58:50 p.m. UTC+7 golde...@gmail.com wrote:

> Can not agree any more. Compiler's job, it's duty, is to translate the 
> human readable code into binary 0 and 1. Human readability should take 
> precedence over the compiler complexity and even performance.
>
> 在 2020年7月15日星期三 UTC+8下午12:45:41，robert engels写道：
>>
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. 
>> Seems better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages). 
>>
>> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  
>> wrote: 
>> > 
>> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>> wrote: 
>> >> 
>> >> This feels a little better, but honestly I'm still all for angle 
>> brackets or like Watson suggested, guillamets. 
>> >> 
>> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 
>> >> fn[T1](fn2[T2](fn3[T3](v))) // 2 
>> >> fn(fn2(fn3(v))) // 3 
>> >> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4 
>> >> 
>> >> To me, with a background in C++ and Typescript and a little bit of 
>> Rust, #3 and #4 are just natural and easier to read. 
>> > 
>> > The advantage of parentheses is that the language already uses 
>> > parentheses for lists in various places.  Of course that is also the 
>> > disadvantage. 
>> > 
>> > When considering something other than parentheses, I encourage people 
>> > to look for objective reasons why one syntax is better than another. 
>> > It's going to be different from other aspects of the language.  So 
>> > what reason would we have for preferring one syntax over another? 
>> > 
>> > For example: 
>> > 
>> > Robert already gave reasons why square brackets are better than angle 
>> brackets. 
>> > 
>> > The disadvantage of guillemets is that they are hard to type on many 
>> > keyboards.  So to me either square brackets or angle brackets would be 
>> > better than guillemets. 
>> > 
>> > The disadvantage of a two character sequence such as <: :> is that it 
>> > is more typing.  So again either square brackets or angle brackets 
>> > seem to me to be better. 
>> > 
>> > An example of a reason that square brackets might be a poor choice 
>> > would be ambiguous parsing, or cases where the code is harder to read. 
>> > 
>> > It's true that some other languages use angle brackets, but Go already 
>> > does many things differently.  That is only a minor advantage for 
>> > angle brackets.  To me at least it does not outweigh the 
>> > disadvantages. 
>> > 
>> > In short, please try to provide reasons for a different syntax.  "It 
>> > looks good" is a valid reason, but please try to explain why it looks 
>> > better than square brackets or parentheses. 
>> > 
>> > Thanks. 
>>
> > 
>> > Ian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group. 
>>
> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to golan...@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/38f57f16-5014-491e-9437-278d9dbd499an%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[goldenbull]

Can not agree any more. Compiler's job, it's duty, is to translate the 
human readable code into binary 0 and 1. Human readability should take 
precedence over the compiler complexity and even performance.

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

Re: [go-nuts] Generics and parentheses

[roger peppe]

On Sat, 18 Jul 2020, 13:25 Jan Mercl, <0xj...@gmail.com> wrote:

> On Sat, Jul 18, 2020 at 1:39 PM roger peppe  wrote:
>
> > I didn't say there was exactly one construct for each kind of name
> definition. In current Go, when a name is defined, it's defined inside a
> construct that is explicitly about defining that name. By contrast, in your
> proposal, we take an arbitrary type and add a dollar qualifier on a name
> somewhere inside it, and that turns the construct into a definition. That
> doesn't feel very Go-like to me.
>
> I think about type parameters in the same way as variables. We don't
> list all the variables in a function in a special list.


The variables in a function aren't part of its publicly visible API.

A _value_
> variable holds a number, for instance. A type parameter holds a
> _type_. Both variable and type parameters are declared where
> necessary, not upfront. Well, the parameter list of a function is an
> upfront list, but that's the only place.
>

It's an important distinction to make: the parameter list of a function is
part of its type definition the same way that the type parameter list of a
generic function is part of its type definition.

Another way to think about type parameters, let me call them also type
> variables, is that value variables are a run time thing while type
> variables exist only at compile time. Otherwise they seem pretty
> similar to me.


> > It's an arbitrary place because it's somewhere buried inside the generic
> type
> > or function. ISTM that it's not great that the form of the types or code
> should
> > directly determine the order of the type parameters. To take an example,
> > say I have some code that uses some generic container defined externally:
>
> Ok, I think now I understand better.
>
> > type S struct {
> > container *external.Container@T1@T2
> > }
>
> Note this would be invalid under the alternative proposal. The correct
> form would have to be:
>
> type S struct {
> container *external.Container@$T1@$T2
> }
>
> And with the order fixing hack (Types is an example. Whatever name
> works, even _, but making  it exported enables it to be shown in
> godocs):
>
> type S struct {
> Types [0]struct{$T1, $T2}
>

I think you'd need a semicolon there, not a comma, for the record (and I
think that gofmt would format this differently).

   container *external.Container@T1@T2
> }
>

What if S isn't a struct type?


>
> > Now what if we want to change the private field to use some alternative
> container implementation that happens to take
> > its type arguments in a different order?
> >
> > type S struct {
> > container *other.Container@T2@T1
> > }
>
> type S struct {
> Types [0]struct{$T1, $T2}
> container *other.Container@T2@T1
> }
>
> IOW, the type parameter list will in some cases appear as it does in
> the original proposal, just not in the prominent position. In other,
> possibly most cases the type parameter list is no longer needed. And
> let's not forget that the original draft also has its "hacks", kind
> of. It requires writing interface{} constraint in some cases


That's just an omission of convenience - all type parameters without
constraints are implicitly "interface{}", so really is the case without
that qualification which is the "hack" (or syntax sugar if you prefer).

, it
> requires parenthesis in other places to resolve parsing ambiguities.
> Both of which the alternative draft does not seem to suffer from.
> Compromises...
>

Which compromises are you referring to here?


> >> I guess that type parameters will in practice appear most often right
> >> in the signature anyway.
> >
> >
> > I'm not keen on this rationalisation. It feels like working around
> something that could have been done correctly from the outset.
>
> It's just my guess. A corpus of real existing generic Go2 code is
> needed to get some real numbers.
>
> > Here's another example:
> >
> > type S struct {}
> >
> > func (s S) Bz() $B {
> > var b B
> > return b
> > }
> >
> > func (s S) Az() $A {
> > var a A
> > return a
> > }
> >
> > AFAICS in this case the ordering of the methods of S influences the
> order of the type parameters required to instantiate S.
> > If we reorder the Az and Bz methods, then we're breaking compatibility.
> What if they're in different files?!
>
> You're right and this hadn't occurred to me before. The only solution
> I can see is:
>
> type S struct { Types [0]{$A, $B} }
>
> But I have to say that this particular example seems rather artificial
> to me.


It may be, it may not, but it's clear to me that the current draft proposal
copes with this case easily and elegantly which yours does not. (also ,
what if S is not a struct type?)

And

maybe then the occasional Types hack does not hurt that
> much. After all, it then makes the alternative draft, in such cases
> only, become in some approximation more or less the 

Re: [go-nuts] Generics and parentheses

[Jan Mercl]

On Sat, Jul 18, 2020 at 1:39 PM roger peppe  wrote:

> I didn't say there was exactly one construct for each kind of name 
> definition. In current Go, when a name is defined, it's defined inside a 
> construct that is explicitly about defining that name. By contrast, in your 
> proposal, we take an arbitrary type and add a dollar qualifier on a name 
> somewhere inside it, and that turns the construct into a definition. That 
> doesn't feel very Go-like to me.

I think about type parameters in the same way as variables. We don't
list all the variables in a function in a special list. A _value_
variable holds a number, for instance. A type parameter holds a
_type_. Both variable and type parameters are declared where
necessary, not upfront. Well, the parameter list of a function is an
upfront list, but that's the only place.

Another way to think about type parameters, let me call them also type
variables, is that value variables are a run time thing while type
variables exist only at compile time. Otherwise they seem pretty
similar to me.

> It's an arbitrary place because it's somewhere buried inside the generic type
> or function. ISTM that it's not great that the form of the types or code 
> should
> directly determine the order of the type parameters. To take an example,
> say I have some code that uses some generic container defined externally:

Ok, I think now I understand better.

> type S struct {
> container *external.Container@T1@T2
> }

Note this would be invalid under the alternative proposal. The correct
form would have to be:

type S struct {
container *external.Container@$T1@$T2
}

And with the order fixing hack (Types is an example. Whatever name
works, even _, but making  it exported enables it to be shown in
godocs):

type S struct {
Types [0]struct{$T1, $T2}
container *external.Container@T1@T2
}

> Now what if we want to change the private field to use some alternative 
> container implementation that happens to take
> its type arguments in a different order?
>
> type S struct {
> container *other.Container@T2@T1
> }

type S struct {
Types [0]struct{$T1, $T2}
container *other.Container@T2@T1
}

IOW, the type parameter list will in some cases appear as it does in
the original proposal, just not in the prominent position. In other,
possibly most cases the type parameter list is no longer needed. And
let's not forget that the original draft also has its "hacks", kind
of. It requires writing interface{} constraint in some cases, it
requires parenthesis in other places to resolve parsing ambiguities.
Both of which the alternative draft does not seem to suffer from.
Compromises...

>> I guess that type parameters will in practice appear most often right
>> in the signature anyway.
>
>
> I'm not keen on this rationalisation. It feels like working around something 
> that could have been done correctly from the outset.

It's just my guess. A corpus of real existing generic Go2 code is
needed to get some real numbers.

> Here's another example:
>
> type S struct {}
>
> func (s S) Bz() $B {
> var b B
> return b
> }
>
> func (s S) Az() $A {
> var a A
> return a
> }
>
> AFAICS in this case the ordering of the methods of S influences the order of 
> the type parameters required to instantiate S.
> If we reorder the Az and Bz methods, then we're breaking compatibility. What 
> if they're in different files?!

You're right and this hadn't occurred to me before. The only solution
I can see is:

type S struct { Types [0]{$A, $B} }

But I have to say that this particular example seems rather artificial
to me. And maybe then the occasional Types hack does not hurt that
much. After all, it then makes the alternative draft, in such cases
only, become in some approximation more or less the same as the
original one - with the explicit type parameter list. While
substantially less verbose in other, again possibly more common cases.

>> It's subjective, so saying I like it does not matter. Not sure what is
>> meant by "the merging of reference and definition", can you please
>> clarify?
>
>
> I mean that we have one place that's both defining new names and acting as a 
> type declaration. It feels to me like you're really trying to avoid defining 
> the generic types as parameters, but you end up with them as implicitly 
> declared parameters anyway, with some additional problems picked up along the 
> way.

I like the note from @bugpowder (another example why I see the @ sign
as a natural fit) that you can think of type parameters as the
property of a name like in exported vs non exported names. Exported
names are also nowhere explicitly _declared_ as being exported. They
are just such when they start with a capital letter in the place where
they are _used_. So type parameters may be thought about like being
such when they start with the $ sign.

Very subjective, but it makes sense to 

Re: [go-nuts] Generics and parentheses

[roger peppe]

On Sat, 18 Jul 2020 at 11:05, Jan Mercl <0xj...@gmail.com> wrote:

> On Sat, Jul 18, 2020 at 11:12 AM roger peppe  wrote:
>
> Thanks for taking time to think about it.
>
> > A few reasons that I'm not keen on your $, @ proposal:
> >
> > - elsewhere in Go, when a name is defined, there is one clear construct
> that defines it, not an arbitrary place within a type expression. That's
> not the case in your proposal.
>
> I don't think variables are declared in just one construct.


I didn't say there was exactly one construct for each *kind* of name
definition. In current Go, when a name is defined, it's defined inside a
construct that is explicitly about defining that name. By contrast, in your
proposal, we take an arbitrary type and add a dollar qualifier on a name
somewhere inside it, and that turns the construct into a definition. That
doesn't feel very Go-like to me.

The term "type expression" does not appear in [1], so let me now
> assume you meant "type literal" and/or just "type" as that includes
> defined types.
>

Yes, just "type" is sufficient, although that term has two purposes - it
can refer both to the program text that declares the type and to the actual
type itself once defined. I was using "type expression" in an attempt to
say the former.

The alternative proposal makes names starting with $ to mean a type
> parameter right at the tokenizer. In the same way as variable
> declaration is accepted by the grammar only in certain contexts, type
> parameters are accepted in the alternative proposal only in the
> context of a type literal, where a type name is allowed. Nowhere else.
>
> var a T
> var a $T
>
> var a map[T]U
> var a map[$T]U
> var a map[$T]$U
> var a map[T]$U
>
> In the original proposal a new place where type can appear is the
> instantiation of a generic type. Same for the alternative draft:
>
> foo(int)(42) // original, predeclared type
> foo@int(42) // alternative
>
> func foo(type T)(x T) { // original
> bar(T)(x) // instantiate bar with type parameter T
> }
>
> func foo(x $T) { // alternative
> bar@T(x) // instantiate bar with type parameter T, the $ sign
> is optional as T was already declared above
> }
>
> So I'm not sure where "arbitrary place" comes from. Note that the
> alternative draft specifies the type parameter declaration must occur
> at its first lexical occurrence.
>

It's an arbitrary place because it's somewhere buried inside the generic
type
or function. ISTM that it's not great that the form of the types or code
should
directly determine the order of the type parameters. To take an example,
say I have some code that uses some generic container defined externally:

type S struct {
container *external.Container@T1@T2
}

To make an instance of S, we need to mention the types in the same order
that we gave them to the external.Container type:

S@string@int

Now what if we want to change the private field to use some alternative
container implementation that happens to take
its type arguments in a different order?

type S struct {
container *other.Container@T2@T1
}

This is an API-breaking change, but it's both non-obvious and not entirely
trivial to work around (we'll need to define our own wrapper type for
other.Container that has the same type parameter order).


> func f(x $T) T { ... } // Is valid in the alternative draft
> func f(x T) $T { ... } // Is not valid in the alternative draft
>
> > - the ordering of the type parameters is important, but is implicit in
> the ordering of the type expressions rather than explicit. The order of the
> type parameters may not even be visible to an external consumer of an API
> (for example, consider a function that returns a generic struct where the
> only generic elements are private fields). Reordering fields within a
> struct could affect the type parameter order - something that should be
> possible to do backwardly compatibly.
>
> This is true and to an extent was mentioned in the alternative draft.
> There's a possible hack for fixing the order in a function and/or a
> struct by listing the prefered order using blank (underscore) variable
> declarations or zero sized fields, but that's ugly. Wait, is it
> really? Firstly, the need for that will probably not be common,
> secondly `var _ myInterface = (*myType)(nil)` etc. is a common idiom
> and it's rather similar to var _ $T; var _ $U, isn't it?


> I guess that type parameters will in practice appear most often right
> in the signature anyway.
>

I'm not keen on this rationalisation. It feels like working around
something that could have been done correctly from the outset.

>
> > - it's strictly less general than the original proposal. There's no way
> to write a generic function that doesn't mention the generic type as part
> of its signature. For example, you couldn't write this function:
> >
> > func zeroPtrInterface[type T]() interface{} {
> > return new(T)
> > }
>
> Example from the 

Re: [go-nuts] Generics and parentheses

[bugpowder]

On Sat, Jul 18, 2020 at 12:12 PM roger peppe  wrote:

>
> - elsewhere in Go, when a name is defined, there is one clear construct
>> that defines it, not an arbitrary place within a type expression. That's
>> not the case in your proposal.
>>
>
On the other hand, $/@ is not dissimilar to using the uppercase first
letter to denote a "publicly" exposed name, that is, encoding a property
into the name.


> - I'm not keen on the @, $ syntax. It co-opts not just one but two new
> symbols into the Go syntax, and I suspect that the merging of reference and
> definition will make the resulting code hard to read.
>

I'd say that introducing special-purpose symbols instead of re-using the
same undifferentiated constructs used elsewhere in the language just with a
string qualifier like "type" added makes it easier to read, and not lose it
in the sameness of declaring parameter lists and return types, 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/CAACdnTBokpa0Fdo22WvaNx3opkocBHRsMWxH-t6ESsNu5a3XcA%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Jan Mercl]

On Sat, Jul 18, 2020 at 11:12 AM roger peppe  wrote:

Thanks for taking time to think about it.

> A few reasons that I'm not keen on your $, @ proposal:
>
> - elsewhere in Go, when a name is defined, there is one clear construct that 
> defines it, not an arbitrary place within a type expression. That's not the 
> case in your proposal.

I don't think variables are declared in just one construct. Some ways
that come to my mind immediately:

var a = 42

a := 42

func f(a int)  {...}

All are clear and that's good. All are allowed just in their
respective contexts as exemplified above. For example, the short
variable definition is not allowed within the list of function
parameters.

The term "type expression" does not appear in [1], so let me now
assume you meant "type literal" and/or just "type" as that includes
defined types.

The alternative proposal makes names starting with $ to mean a type
parameter right at the tokenizer. In the same way as variable
declaration is accepted by the grammar only in certain contexts, type
parameters are accepted in the alternative proposal only in the
context of a type literal, where a type name is allowed. Nowhere else.

var a T
var a $T

var a map[T]U
var a map[$T]U
var a map[$T]$U
var a map[T]$U

In the original proposal a new place where type can appear is the
instantiation of a generic type. Same for the alternative draft:

foo(int)(42) // original, predeclared type
foo@int(42) // alternative

func foo(type T)(x T) { // original
bar(T)(x) // instantiate bar with type parameter T
}

func foo(x $T) { // alternative
bar@T(x) // instantiate bar with type parameter T, the $ sign
is optional as T was already declared above
}

So I'm not sure where "arbitrary place" comes from. Note that the
alternative draft specifies the type parameter declaration must occur
at its first lexical occurrence.

func f(x $T) T { ... } // Is valid in the alternative draft
func f(x T) $T { ... } // Is not valid in the alternative draft

> - the ordering of the type parameters is important, but is implicit in the 
> ordering of the type expressions rather than explicit. The order of the type 
> parameters may not even be visible to an external consumer of an API (for 
> example, consider a function that returns a generic struct where the only 
> generic elements are private fields). Reordering fields within a struct could 
> affect the type parameter order - something that should be possible to do 
> backwardly compatibly.

This is true and to an extent was mentioned in the alternative draft.
There's a possible hack for fixing the order in a function and/or a
struct by listing the prefered order using blank (underscore) variable
declarations or zero sized fields, but that's ugly. Wait, is it
really? Firstly, the need for that will probably not be common,
secondly `var _ myInterface = (*myType)(nil)` etc. is a common idiom
and it's rather similar to var _ $T; var _ $U, isn't it?

I guess that type parameters will in practice appear most often right
in the signature anyway.

> - it's strictly less general than the original proposal. There's no way to 
> write a generic function that doesn't mention the generic type as part of its 
> signature. For example, you couldn't write this function:
>
> func zeroPtrInterface[type T]() interface{} {
> return new(T)
> }

Example from the alternative draft, page 2:

func NewFoo(limit int) Foo {
r := new($T Fooer)
r.SetLimit(limit)
return r
}

So the "couldn't write this" example is:

func zeroPtrInterface() interface{} {
 return new($T)
}

> - I'm not keen on the @, $ syntax. It co-opts not just one but two new 
> symbols into the Go syntax, and I suspect that the merging of reference and 
> definition will make the resulting code hard to read.

It's subjective, so saying I like it does not matter. Not sure what is
meant by "the merging of reference and definition", can you please
clarify?



  [1]: "Type Parameters - Draft Design",
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md
by Ian Lance Taylor and Robert Griesemer, June 16, 2020.

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

Re: [go-nuts] Generics and parentheses

[roger peppe]

On Thu, 16 Jul 2020, 14:38 Jan Mercl, <0xj...@gmail.com> wrote:

> On Thu, Jul 16, 2020 at 3:12 PM 'Axel Wagner' via golang-nuts
>  wrote:
>
> > I dislike the idea of using $ and @ because I don't want to add new
> symbols to the language, if it can be avoided. In general I'd argue that Go
> tends to use keywords instead of symbols to convey meaning - e.g. we don't
> write `a -> b`, but `func(a) b`. There are exceptions (pointers are a big
> one) of course, but Go is still pretty light on symbols.
> > I think the overuse of symbols to convey semantics is a huge reason that
> I find perl and Haskell so unreadable, personally.
>
> There are 31 printable, non blank, non-digit, non-letter ASCII
> symbols. Go (lexical grammar) currently uses 27 of them. I'm not sure
> if using 27 of 31 vs using 29 out 31 makes a notable difference. (I
> have not counted smybol groups like ":=" ">=", "<-" etc., but that
> makes the number of symbols used in Go only bigger, not smaller.)
>
> But of course, a keyword would work as well. For example, $ can be
> replaced with no semantic change with 'type'. And @ can be dropped
> while keeping the original draft syntax for type instantiation - and
> the original parsing ambiguities. Then we can have something like
>
> Original:
>
> func Keys(type K comparable, V interface{})(m map[K]V) []K { ... }
> s := Keys(int, string)(m)
>
> Alternative-AW:
>
> func Keys(m map[type K comparable]type V) []K
> s := Keys(int, string)(m)
>
> FTR: In the alternative draft I missed the `~` (tilde) character, so
> there are not 3 but actually 4 ASCII symbols not used by Go.
>
> But I like the $, @ option because the language change is pushed
> "down" to be based mainly in the lexer grammar.


A few reasons that I'm not keen on your $, @ proposal:

- elsewhere in Go, when a name is defined, there is one clear construct
that defines it, not an arbitrary place within a type expression. That's
not the case in your proposal.

- the ordering of the type parameters is important, but is implicit in the
ordering of the type expressions rather than explicit. The order of the
type parameters may not even be visible to an external consumer of an API
(for example, consider a function that returns a generic struct where the
only generic elements are private fields). Reordering fields within a
struct could affect the type parameter order - something that should be
possible to do backwardly compatibly.

- it's strictly less general than the original proposal. There's no way to
write a generic function that doesn't mention the generic type as part of
its signature. For example, you couldn't write this function:

func zeroPtrInterface[type T]() interface{} {
return new(T)
}

- I'm not keen on the @, $ syntax. It co-opts not just one but two new
symbols into the Go syntax, and I suspect that the merging of reference and
definition will make the resulting code hard to read.

For the record, I support the [] syntax. The analogy between generic
functions and maps makes sense to me, and I think it's sufficiently
syntactically distinct to avoid the issues with round brackets. My main
reservation is about backward compatible evolution of generic types. It's
not possible to add a new type parameter in a backwardly compatible way. In
larger systems, I wonder if that might turn out to be a significant issue.

  cheers,
rog.

I haven't made any
> attempt to write a parser for the alternative draft, but I think this
> makes the changes on top of the existing parser pretty minimal. The
> original draft, on the other hand, needs IMO much more changes.
>
> --
> 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-VwE2URengdE0Cd7sPQNCm5%3DTm5%3DaUS8kMwOpEw%3DXjJyg%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/CAJhgach5eUJvZ6ek5SZzoLW%3Dgi7axXRUbtz3-ukbLLSCVLAiOw%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Kulics Wu]

Why not try the design of Feel language,
There is no ambiguity and no more code.
```
type [Item T] struct { 
Value T 
} 
func (it [Item T]) Print() { 
println(it.Value) 
} 
func [TestGenerics T V]() { 
var a = [Item T]{} 
a.Print() 
var b = [Item V]{} 
b.Print()
 } 
func main() {
 [TestGenerics int string]() 
}
```
On Thursday, July 16, 2020 at 3:16:51 PM UTC+8 Henrik Johansson wrote:

> This is good. I have been reaching for a consistency check and this just 
> may be it.
>
> On Thu, Jul 16, 2020 at 12:04 AM 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
>> > And the use of [ ] in map is more semantically associated with its
>> > conventional use as an element accessor in arrays / slices, not with
>> > some more general kind of type parameter.
>>
>> The [] syntax can be viewed as an indexing operation perfectly well in
>> the context of generics; a generic function or type is a map of
>> implementations or types and so the [] syntax is a type index into that
>> map, just as map[T1]T2 is a type index into the builtin generic map
>> type. This is not mental stretch.
>>
>>
>> -- 
>> 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/abe84ff5abefe2815137bea9cb83eb9e8d5fdafb.camel%40kortschak.io
>> .
>>
>

-- 
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/dda8c231-0390-4506-a82f-c051ba370942n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Jan Mercl]

On Thu, Jul 16, 2020 at 3:12 PM 'Axel Wagner' via golang-nuts
 wrote:

> I dislike the idea of using $ and @ because I don't want to add new symbols 
> to the language, if it can be avoided. In general I'd argue that Go tends to 
> use keywords instead of symbols to convey meaning - e.g. we don't write `a -> 
> b`, but `func(a) b`. There are exceptions (pointers are a big one) of course, 
> but Go is still pretty light on symbols.
> I think the overuse of symbols to convey semantics is a huge reason that I 
> find perl and Haskell so unreadable, personally.

There are 31 printable, non blank, non-digit, non-letter ASCII
symbols. Go (lexical grammar) currently uses 27 of them. I'm not sure
if using 27 of 31 vs using 29 out 31 makes a notable difference. (I
have not counted smybol groups like ":=" ">=", "<-" etc., but that
makes the number of symbols used in Go only bigger, not smaller.)

But of course, a keyword would work as well. For example, $ can be
replaced with no semantic change with 'type'. And @ can be dropped
while keeping the original draft syntax for type instantiation - and
the original parsing ambiguities. Then we can have something like

Original:

func Keys(type K comparable, V interface{})(m map[K]V) []K { ... }
s := Keys(int, string)(m)

Alternative-AW:

func Keys(m map[type K comparable]type V) []K
s := Keys(int, string)(m)

FTR: In the alternative draft I missed the `~` (tilde) character, so
there are not 3 but actually 4 ASCII symbols not used by Go.

But I like the $, @ option because the language change is pushed
"down" to be based mainly in the lexer grammar. I haven't made any
attempt to write a parser for the alternative draft, but I think this
makes the changes on top of the existing parser pretty minimal. The
original draft, on the other hand, needs IMO much more changes.

-- 
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-VwE2URengdE0Cd7sPQNCm5%3DTm5%3DaUS8kMwOpEw%3DXjJyg%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

['Axel Wagner' via golang-nuts]

I dislike the idea of using $ and @ because I don't want to add new symbols
to the language, if it can be avoided. In general I'd argue that Go tends
to use keywords instead of symbols to convey meaning - e.g. we don't write
`a -> b`, but `func(a) b`. There are exceptions (pointers are a big one) of
course, but Go is still pretty light on symbols.
I think the overuse of symbols to convey semantics is a huge reason that I
find perl and Haskell so unreadable, personally.

On Thu, Jul 16, 2020 at 2:23 PM Jan Mercl <0xj...@gmail.com> wrote:

> Resending to the list after mistakenly replied off list. My apologies.
>
> 
>
> On Wed, Jul 15, 2020 at 10:59 PM Ian Lance Taylor  wrote:
>
> > Thanks for the detailed writeup.
>
> It might have been too detailed and suffered from low information
> density. Let me amend it with a tl;dr:
>
> 
>
> 1. The main idea is to remove the parenthesized type list while
> keeping exactly 100% of the semantics of the original draft.
>
> 2. $T declares a type parameter. (For the mnemotechnical clue cf. the
> POSIX shell env vars or Tcl vars, to name a few.)
>
> 3. U@V, u-at-v, instantiates generic type U using type argument V.
> (cf.  value instance at address, now type-parameter instantiated at
> type)
>
> 4. Instantiating a generic type W with a type parameter X that is
> declared in the same place means plugging 2 into 3, hence W@$X.
>
> 
>
> The particular syntax is less important here. But it seems to remove
> the parsing ambiguities of the original draft.
>
> Motivational example of a function signature:
>
> Original:
>
> func Keys(type K comparable, V interface{})(m map[K]V) []K
>
> Alternative:
>
> func Keys(m map[$K comparable]$V) []K
>
> 
>
> > I'm a bit concerned about name
> > scoping.
>
> Then I must have miscommunicated something. The intent is to have the
> type parameters live in the exact same scope as in the original draft.
> The comments about $T and T in the same scope just tried to say that
> there cannot be both a type parameter $T and other named, but
> different thing T in the same scope. Exactly as in the original, but
> there the $ sign does not exist, so there's nothing to talk about in
> this regard.
>
> > Also about the fact that constraints can apparently show up
> > anywhere; is that always going to work?
>
> In the original draft a type parameter constraint appears only once,
> next to the type parameter declaration. In the alternative one is the
> same, only once, next to the type parameter declaration. Hence I
> expect the alternative version to work in exactly the same way.
>
> > And I don't think that
> > Vector@$T is going to be all that intuitive for anybody to read.
>
> This is subjective by definition, but I'd like to point out something
> different. We write and read code not by intuition but by using quite
> precise knowledge about the grammar and semantics of the language.
>
> Intuition can of course help us to learn that necessary level of
> knowledge to become a fluent language user.
>
> f(x), for example, is intuitively a function call, because we write
> f(x) in math classes in school.
>
> a+b is intuitively an addition, because that's how we write it in math.
>
> a*b is not very intuitive, because we write multiplication in math as
> ab, a.b, axb. (The last has at least some visual resemblance to the
> asterisk, admitted.)
>
> Okay, now that we know the correct multiplication symbol, what an
> unary multiplication is intuitively supposed to mean and why it
> actually denotes dereferencing a pointer or pointer-ness of a type?
>
> a^b is intuitively exponentiation, because that's how we write it in
> math. But it's actually a xor b in Go.
>
> The conclusion is, sometimes intuition helps in learning the language,
> other times it can hurt. The only thing that matters at the end of the
> day is knowing the language and that's no more connected much with
> intuition.
>
> --
> 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-WEv4uoa0eSyE5M2yimn6tPJ7_vHFxPW5W2mCk1zTZfmg%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/CAEkBMfE5M%2BqQ7czhSULbpcfHwcO9QOF98Uw6P18f-CUP6ia80A%40mail.gmail.com.

Fwd: [go-nuts] Generics and parentheses

[Jan Mercl]

Resending to the list after mistakenly replied off list. My apologies.



On Wed, Jul 15, 2020 at 10:59 PM Ian Lance Taylor  wrote:

> Thanks for the detailed writeup.

It might have been too detailed and suffered from low information
density. Let me amend it with a tl;dr:



1. The main idea is to remove the parenthesized type list while
keeping exactly 100% of the semantics of the original draft.

2. $T declares a type parameter. (For the mnemotechnical clue cf. the
POSIX shell env vars or Tcl vars, to name a few.)

3. U@V, u-at-v, instantiates generic type U using type argument V.
(cf.  value instance at address, now type-parameter instantiated at
type)

4. Instantiating a generic type W with a type parameter X that is
declared in the same place means plugging 2 into 3, hence W@$X.



The particular syntax is less important here. But it seems to remove
the parsing ambiguities of the original draft.

Motivational example of a function signature:

Original:

func Keys(type K comparable, V interface{})(m map[K]V) []K

Alternative:

func Keys(m map[$K comparable]$V) []K



> I'm a bit concerned about name
> scoping.

Then I must have miscommunicated something. The intent is to have the
type parameters live in the exact same scope as in the original draft.
The comments about $T and T in the same scope just tried to say that
there cannot be both a type parameter $T and other named, but
different thing T in the same scope. Exactly as in the original, but
there the $ sign does not exist, so there's nothing to talk about in
this regard.

> Also about the fact that constraints can apparently show up
> anywhere; is that always going to work?

In the original draft a type parameter constraint appears only once,
next to the type parameter declaration. In the alternative one is the
same, only once, next to the type parameter declaration. Hence I
expect the alternative version to work in exactly the same way.

> And I don't think that
> Vector@$T is going to be all that intuitive for anybody to read.

This is subjective by definition, but I'd like to point out something
different. We write and read code not by intuition but by using quite
precise knowledge about the grammar and semantics of the language.

Intuition can of course help us to learn that necessary level of
knowledge to become a fluent language user.

f(x), for example, is intuitively a function call, because we write
f(x) in math classes in school.

a+b is intuitively an addition, because that's how we write it in math.

a*b is not very intuitive, because we write multiplication in math as
ab, a.b, axb. (The last has at least some visual resemblance to the
asterisk, admitted.)

Okay, now that we know the correct multiplication symbol, what an
unary multiplication is intuitively supposed to mean and why it
actually denotes dereferencing a pointer or pointer-ness of a type?

a^b is intuitively exponentiation, because that's how we write it in
math. But it's actually a xor b in Go.

The conclusion is, sometimes intuition helps in learning the language,
other times it can hurt. The only thing that matters at the end of the
day is knowing the language and that's no more connected much with
intuition.

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

Re: [go-nuts] Generics and parentheses

[Henrik Johansson]

This is good. I have been reaching for a consistency check and this just
may be it.

On Thu, Jul 16, 2020 at 12:04 AM 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> > And the use of [ ] in map is more semantically associated with its
> > conventional use as an element accessor in arrays / slices, not with
> > some more general kind of type parameter.
>
> The [] syntax can be viewed as an indexing operation perfectly well in
> the context of generics; a generic function or type is a map of
> implementations or types and so the [] syntax is a type index into that
> map, just as map[T1]T2 is a type index into the builtin generic map
> type. This is not mental stretch.
>
>
> --
> 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/abe84ff5abefe2815137bea9cb83eb9e8d5fdafb.camel%40kortschak.io
> .
>

-- 
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/CAKOF696MO7RsR7kheXV4pKzSV4HQ7cGrAhH-YaC-KedQPWxx7g%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

['Dan Kortschak' via golang-nuts]

On Wed, 2020-07-15 at 18:09 -0700, lotus.developer.mas...@gmail.com
wrote:
> Personally think this way is easier to read. In this way, I wrote a
> few examples, which may be different from the creator

Please post in unstyled plain text. It is almost impossible to read the
code examples you have there in dark text on a black background.


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

Re: [go-nuts] Generics and parentheses

[lotus . developer . master]

Personally think this way is easier to read. In this way, I wrote a few 
examples, which may be different from the creator

* For example: define a node
type Node struct{
prev *Node
data T //data *T
next *Node
}
* Call request
var node Node

* Let's take another example, such as the maximum value
* What to do when different types require the maximum value
type maxIntCallback func(one,two int) bool
type maxFloat64Callback func(one,two float64 /*float32*/) bool
//...other types

//If you want to use it, such as a certain function. func 
intCompare(one,two int,max Max) int
//1.
one,two := 10,20
max := Compare(one,two,_Max)
fmt.Println(max)


func _Max(one,two int) int {
   max := one
   if max > two{
   return max
   }
   return two
}
func intCompare(one,two int,max Max) int {
   return max(one,two)
}

//2.
one,two := 10,20
   var max = Compare(one,two, func(one, two int) int {
   max := one
   if max > two{
   return max
   }
   return two
})

* Although the above example can also be done using interfaces, it's like 
all parameters in Java use Object as the type, so it is always bad.

* Here is a generic example

type maxCallback func(one,two T) T
func compare(one,two T,call maxCallback) T {
   return call(one,two)
}

//int
one,two := 10,20
compare(one,two,func(one,two int ) int {
   //...
})

//float
one,two := 10.0,20.0
compare(one,two,func(one,two float64 ) float64 {
   //...
})

* In this way, it is easier to read and people-oriented



在 2020年7月15日星期三 UTC+8下午1:06:24，Paul Johnston写道：
>
> If the generic expression  was always attached/constrained to the 
> "type" or "func" keyword (rather than the type or function name), perhaps 
> this would decrease the lookahead problems with lexing?  For example:
>
> *type Point struct {*
> *x, y int*
> *data T*
> *}*
>
> *type Transformer interface {*
> *Transform(R) S*
> *}*
>
> *func Stringify(s []T) string {*
> *}*
>
> *type Vector []T*
>
>
>
> On Tuesday, July 14, 2020 at 10:45:41 PM UTC-6 ren...@ix.netcom.com wrote:
>
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. 
>> Seems better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages). 
>>
>> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  
>> wrote: 
>> > 
>> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>> wrote: 
>> >> 
>> >> This feels a little better, but honestly I'm still all for angle 
>> brackets or like Watson suggested, guillamets. 
>> >> 
>> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 
>> >> fn[T1](fn2[T2](fn3[T3](v))) // 2 
>> >> fn(fn2(fn3(v))) // 3 
>> >> fn«T1»(fn2«T2»(fn3«T3»v))) // 4 
>> >> 
>> >> To me, with a background in C++ and Typescript and a little bit of 
>> Rust, #3 and #4 are just natural and easier to read. 
>> > 
>> > The advantage of parentheses is that the language already uses 
>> > parentheses for lists in various places. Of course that is also the 
>> > disadvantage. 
>> > 
>> > When considering something other than parentheses, I encourage people 
>> > to look for objective reasons why one syntax is better than another. 
>> > It's going to be different from other aspects of the language. So 
>> > what reason would we have for preferring one syntax over another? 
>> > 
>> > For example: 
>> > 
>> > Robert already gave reasons why square brackets are better than angle 
>> brackets. 
>> > 
>> > The disadvantage of guillemets is that they are hard to type on many 
>> > keyboards. So to me either square brackets or angle brackets would be 
>> > better than guillemets. 
>> > 
>> > The disadvantage of a two character sequence such as <: :> is that it 
>> > is more typing. So again either square brackets or angle brackets 
>> > seem to me to be better. 
>> > 
>> > An example of a reason that square brackets might be a poor choice 
>> > would be ambiguous parsing, or cases where the code is harder to read. 
>> > 
>> > It's true that some other languages use angle brackets, but Go already 
>> > does many things differently. That is only a minor advantage for 
>> > angle brackets. To me at least it does not outweigh the 
>> > disadvantages. 
>> > 
>> > In short, please try to provide reasons for a different syntax. "It 
>> > looks good" is a valid reason, but please try to explain why it looks 
>> > better than square brackets or parentheses. 
>> > 
>> > Thanks. 
>> > 
>> > Ian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to golang-nuts...@googlegroups.com. 
>> > To view this discussion on the web visit 

Re: [go-nuts] Generics and parentheses

[Randall Oreilly]

Perhaps another source of resistance to < > is the trauma many of us have from 
its major obfuscation of C++ code?

- Randy

> On Jul 15, 2020, at 3:13 PM, Yaw Boakye  wrote:
> 
> To summarize the thread so far:
> 
> - parenthesis is a no-no
> - angle brackets are popular/common but that alone doesn't make good 
> argument. some languages have already deviated. scala is popular, uses square 
> instead of angle brackets.
> - go's current pseudo-generic data structure, the map, already uses the 
> square bracket (e.g. map[int]int), a vote for square brackets. internal 
> syntax consistency is key.
> 
> On Wed 15 Jul 2020 at 23:04 'Dan Kortschak' via golang-nuts 
>  wrote:
> On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> > And the use of [ ] in map is more semantically associated with its
> > conventional use as an element accessor in arrays / slices, not with
> > some more general kind of type parameter.
> 
> The [] syntax can be viewed as an indexing operation perfectly well in
> the context of generics; a generic function or type is a map of
> implementations or types and so the [] syntax is a type index into that
> map, just as map[T1]T2 is a type index into the builtin generic map
> type. This is not mental stretch.
> 
> 
> -- 
> 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/abe84ff5abefe2815137bea9cb83eb9e8d5fdafb.camel%40kortschak.io.
> -- 
> 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/CAPJoGXsM%2BuzfS_2sNBXP2d4z%3DvC-2gHOu_QS%3DL3PSQKkx6_drg%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/2A62BAF3-6D6E-45B2-A3DE-824AA784724D%40colorado.edu.

Re: [go-nuts] Generics and parentheses

[Denis Cheremisov]

The big argument I always found less and greater signs to be not visually 
distinctive enough, at least with fonts I am using. [ and ] are larger and 
I was really happy with them in Scala although I dislike the language in 
general. 
Seriously though, the real big argument is [] are already used with in two 
of three generic types ([]T, map[K]V, only is chan T is different). And 
there's a huge argument, with the performance of simple tools like gofmt, 
etc.

среда, 15 июля 2020 г. в 23:21:38 UTC+3, frave...@gmail.com: 

> On Jul 15, 2020, at 2:48 PM, Ian Lance Taylor  wrote:
> > 
> > More seriously, though, let's look closely at Robert's example:
> > 
> > a, b = w < x, y > (z)
>
> TBH, I think a big argument in favor of square brackets over angle 
> brackets is that they ascend above the center line in most typefaces, which 
> makes them much more visually distinct from the shorter operators and many 
> lowercase letters. This is similar to parens and curly braces while still 
> being visually distinct from both.
>
> As something that is essentially a metaparameter which is similar to, but 
> distinct in function to the arguments in parens, there's a lot of good 
> consistency going on there that I personally find easier to visually scan 
> without syntax highlighting than I do angle brackets. But that could be 
> just me, and it does depend on typeface, so take it with whatever grains of 
> salt you need to.
>
>
> - 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/1c240cb4-82c7-4abb-b00f-970102bc746an%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

On Wed, Jul 15, 2020 at 3:27 PM Bakul Shah  wrote:
>
> The syntax rule I envisioned was this:
> type: ... | type generic-type | ...
>
> To me, using full parenthesization, this would be
> func() int pair pair" == "((func() int) pair)pair --(1)
> What you seem to want is
> (func() (int pair)) pair --(2)
>
> Contrast that with
> pair[pair[func() int]] --(1)
> and
> pair[func()pair[int]] --(2)
>
> As I see it, the alternate syntax is no worse for extreme cases but much 
> better for the common case.

What I was trying to get at wasn't really whether the syntax is better
or worse when parenthesized correctly.  It was about how it reads
without parentheses, and how people will know when to add parentheses.
With the square brackets it seems clear to me what the cases mean and
how to write them.  With the prefix notation it seems less clear.



> The second issue is the usage for generic functions. Contrast
>
> (float64, int)PowN(1.2, 3)
> with
> PowN[float64, int](1.2, 3)
> or currently
> PowN(float64, int)(1.2, 3)
>
> I find the alternate syntax easier because conceptually the concrete types  
> used to select a specific concrete function is a different activity than 
> passing arguments to a function at runtime so IMHO they should be visually 
> different.  It is almost like  C style cast. Think of it as casting a generic 
> function (or type) to a concrete function or type!

Personally I find it more natural to think of the types as arguments.
And that is how most popular languages handle them too.  I understand
that you feel differently.

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/CAOyqgcVo5HOob9Mywe%2Bd%2BDCy77WmWwNq%2BLAV7hTUAY%3DLQjmiCA%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

['Dan Kortschak' via golang-nuts]

On Wed, 2020-07-15 at 15:27 -0700, Bakul Shah wrote:
> The second issue is the usage for generic functions. Contrast
> 
>   (float64, int)PowN(1.2, 3)
> with
>   PowN[float64, int](1.2, 3)
> or currently
>   PowN(float64, int)(1.2, 3)
> 
> I find the alternate syntax easier because conceptually the concrete
> types  used to select a specific concrete function is a different
> activity than passing arguments to a function at runtime so IMHO they
> should be visually different.  It is almost like  C style cast. Think
> of it as casting a generic function (or type) to a concrete function
> or type!

This is going to be a fairly individual thing though, I find
PowN[float64, int](1.2, 3) much easier to read.


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

Re: [go-nuts] Generics and parentheses

[Bakul Shah]

> On Jul 15, 2020, at 1:49 PM, Ian Lance Taylor  wrote:
> 
> On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah  wrote:
>> 
>> I don't much like square brackets or angle brackets or guillemets. But here 
>> is a different way
>> of reducing the need for parentheses at least for the common case:
>> 
>> A proposal for fewer irritating parentheses!
>> 
>> One thing to note is that generic functions & types are *different* from
>> existing things like const, func, type, var. As such they should have their
>> own declaration marker. For example
>> 
>> gen T   type pair struct { a, b T } // contrast with type pair(type T) ...
>> gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ...
>> gen T   func Print(s []T) {...} // print a slice of T
>> 
>> These function/type/method generics are used by *prepending* the type:
>> 
>> var x int pair // a pair of ints
>> var y (int, int pair) W // here we have to use parentheses
>> int Print([]int{1,2,3}) // print a slice of ints
>> qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
>> ww := (int, int) W pair{{1,2},{3,4}}
>> 
>> This use may seem weird if you are used to C/C++. I find it more readable
>> than having to deal with extra parentheses. "int pair" clearly says a
>> pair of ints and so on. What is more, if in future types are allowed to be
>> *inferred* for generic function calls, you can simply drop the type prefix.
>> 
>> If there is still a parsing ambiguity, I'd suggest adding a - as in int-pair.
>> 
>> Additional type syntax rule:
>> 
>> type: ... | type generic-type| (type-list) generic-type
>> 
>> or
>> 
>> type: ... | type "-" generic-type | (type-list) "-" generic-type
>> 
>> FWIW I thought of this four weeks ago (June 16).
> 
> 
> Thanks for the note.  It's an interesting idea, but I'm not quite sure
> it works to have prefix types with no real delimiters.  It may work to
> write "int pair pair" but does it work to write "func() int pair
> pair"?  That is the type of a pair of functions where each function
> returns the type "int pair".  If we have to start carefully deciding
> where we need to add parentheses then I'm not sure we've gained very
> much by switching to this kind of syntax.

The syntax rule I envisioned was this:
type: ... | type generic-type | ...

To me, using full parenthesization, this would be
func() int pair pair" == "((func() int) pair)pair --(1)
What you seem to want is
(func() (int pair)) pair --(2)

Contrast that with
pair[pair[func() int]] --(1)
and
pair[func()pair[int]] --(2)

As I see it, the alternate syntax is no worse for extreme cases but much better 
for the common case.

The second issue is the usage for generic functions. Contrast

(float64, int)PowN(1.2, 3)
with
PowN[float64, int](1.2, 3)
or currently
PowN(float64, int)(1.2, 3)

I find the alternate syntax easier because conceptually the concrete types  
used to select a specific concrete function is a different activity than 
passing arguments to a function at runtime so IMHO they should be visually 
different.  It is almost like  C style cast. Think of it as casting a generic 
function (or type) to a concrete function or type!


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/65AF00C2-1CAE-4876-84A8-8BADD4A740CE%40iitbombay.org.

Re: [go-nuts] Generics and parentheses

['Dan Kortschak' via golang-nuts]

On Wed, 2020-07-15 at 17:10 -0500, Seebs wrote:
> That said, if people don't like square brackets, I'm totally prepared
> to make worse suggestions until they give up and say square brackets
> aren't that bad.
> 

Let's bring back the special five keywords!

func despiteallobjections F insofaras type T thetruthofthematter (x T) (T, 
error)

There is no parsing ambiguity, the syntax is already familiar to
Gophers and it clearly indicates the intention and the difficulty of
coming up with a sensible generics declaration syntax. This is win win
win!


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

Re: [go-nuts] Generics and parentheses

[Yaw Boakye]

To summarize the thread so far:

- parenthesis is a no-no
- angle brackets are popular/common but that alone doesn't make good
argument. some languages have already deviated. scala is popular, uses
square instead of angle brackets.
- go's current pseudo-generic data structure, the map, already uses the
square bracket (e.g. map[int]int), a vote for square brackets. internal
syntax consistency is key.

On Wed 15 Jul 2020 at 23:04 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> > And the use of [ ] in map is more semantically associated with its
> > conventional use as an element accessor in arrays / slices, not with
> > some more general kind of type parameter.
>
> The [] syntax can be viewed as an indexing operation perfectly well in
> the context of generics; a generic function or type is a map of
> implementations or types and so the [] syntax is a type index into that
> map, just as map[T1]T2 is a type index into the builtin generic map
> type. This is not mental stretch.
>
>
> --
> 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/abe84ff5abefe2815137bea9cb83eb9e8d5fdafb.camel%40kortschak.io
> .
>
-- 
*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/CAPJoGXsM%2BuzfS_2sNBXP2d4z%3DvC-2gHOu_QS%3DL3PSQKkx6_drg%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Seebs]

On Wed, 15 Jul 2020 14:51:17 -0700
jimmy frasche  wrote:

> I didn't care about () except for having to then have extra parens
> around types in a lot of places which was very annoying and came up
> often. If [] fixes that, great!

I was pretty unhappy with () just because there's too many () and it's
hard to tell them apart by eyeball. Even if the parsing isn't strictly
ambiguous, it's annoying to try to decipher; I already feel like too
many things use ()s.

That said, if people don't like square brackets, I'm totally prepared
to make worse suggestions until they give up and say square brackets
aren't that bad.

old proposal:
func F(type T) (x T) (T, error)

new proposal:
func F[type T] (x T) (T, error)

:seebsno:
func F/type T/(x T) (T, error)

Or we could do sed-style "any character can be the delimiter if
you use it where we expect a delimiter", except using "right before
the type keyword", so for instance:
func F!type T!(x T) (T, error)
func Fxtype Tx(x T) (T, error) // yes you can use x

And we could also support regex-style flags on these to resolve
the "how should the compiler actually implement this", by letting you
specify implementation-choice flags:
func F/type T/g(x T) (T, error) // generate specialized code
func F/type T/i(x T) (T, error) // inline
func F/type T/p(x T) (T, error) // print lines to output??!
func F/type T/q(x T) (T, error) // exit compilation early

Not bad enough? No problem! We'll just... use XML. That should help us
win over the enterprise market, right?

  
func F(x T) (T, error)
  


(The indentation is mandatory, of course, with two spaces before the
 tags, and a tab with no leading spaces before the code inside
them.)

If it weren't for the parser things, I'd prefer <> to []. However, I am
also fine with [type T]; it's clear and unambiguous, and gets away from
the "everything goes in ()s" that was my only real complaint about the
proposal.

(And yes I thought of the "unicode characters that happen to look like
angle brackets" idea, but someone already implemented it that way, so
it's not novel.)

-s

-- 
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/20200715171009.535f35a9%40seebsdell.

Re: [go-nuts] Generics and parentheses

['Dan Kortschak' via golang-nuts]

On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote:
> And the use of [ ] in map is more semantically associated with its
> conventional use as an element accessor in arrays / slices, not with
> some more general kind of type parameter.

The [] syntax can be viewed as an indexing operation perfectly well in
the context of generics; a generic function or type is a map of
implementations or types and so the [] syntax is a type index into that
map, just as map[T1]T2 is a type index into the builtin generic map
type. This is not mental stretch.


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

Re: [go-nuts] Generics and parentheses

[jimmy frasche]

I didn't care about () except for having to then have extra parens
around types in a lot of places which was very annoying and came up
often. If [] fixes that, great!

On Wed, Jul 15, 2020 at 2:47 PM Ian Lance Taylor  wrote:
>
> On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly  wrote:
> >
> > Regarding the parsing: as I suggested in my email, but perhaps was unclear, 
> > in case of two conflicting *purely syntactic* interpretations (without 
> > using any type information), you could just choose the more high-frequency 
> > interpretation (i.e., type parameters) and force the programmer to use 
> > additional parens if they actually want the other interpretation.
> >
> > So in the case of the example, w < x, y > (z) is *automatically, 
> > syntactically* interpreted as a function call using 2 type parameters, and 
> > if you want it to be two different relational expressions, you have to wrap 
> > them in parens: (w < x), (y > (z))
> >
> > This latter use is likely to be vanishingly rare (someone could run their 
> > code analysis on it), so this seems like a small inconvenience.  Maybe 
> > there are other such conflicts?  If this is the only one, I don't think it 
> > is sufficient to rule out the use of < >.
> >
> > My mention of the point about gofmt was just that it should get rid of the 
> > seemingly redundant extra paren around (z), but I just tried it and 
> > apparently it does not, even with gofmt -s.  Anyway, the above point 
> > stands: you CAN parse < > correctly by just making purely syntactic choices 
> > in the case of conflicts, and this applies to all Go tools using the same 
> > purely syntactic parsing pass.
>
> That's true.  We could do that.  It's not backward compatible, and it
> doesn't fit the Go 2 transitions plan, but we could do it if we really
> had to.
>
> But we don't really have to.  We can use square brackets instead, or
> we can go back to using parentheses.  This thread suggests that while
> clearly some people prefer angle brackets, it is not a dominant
> consensus.
>
> 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/CAOyqgcVo3d4zrXkGtxPzMUSC%2BJ0ju_B3DsQZj%2B%3D5Ec2%2B3y0%3DSA%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/CANG3jXLSGAd644zrKUOJL1b%2BXObtrvTnP-tFpYyKgY%3DdUei69w%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly  wrote:
>
> Regarding the parsing: as I suggested in my email, but perhaps was unclear, 
> in case of two conflicting *purely syntactic* interpretations (without using 
> any type information), you could just choose the more high-frequency 
> interpretation (i.e., type parameters) and force the programmer to use 
> additional parens if they actually want the other interpretation.
>
> So in the case of the example, w < x, y > (z) is *automatically, 
> syntactically* interpreted as a function call using 2 type parameters, and if 
> you want it to be two different relational expressions, you have to wrap them 
> in parens: (w < x), (y > (z))
>
> This latter use is likely to be vanishingly rare (someone could run their 
> code analysis on it), so this seems like a small inconvenience.  Maybe there 
> are other such conflicts?  If this is the only one, I don't think it is 
> sufficient to rule out the use of < >.
>
> My mention of the point about gofmt was just that it should get rid of the 
> seemingly redundant extra paren around (z), but I just tried it and 
> apparently it does not, even with gofmt -s.  Anyway, the above point stands: 
> you CAN parse < > correctly by just making purely syntactic choices in the 
> case of conflicts, and this applies to all Go tools using the same purely 
> syntactic parsing pass.

That's true.  We could do that.  It's not backward compatible, and it
doesn't fit the Go 2 transitions plan, but we could do it if we really
had to.

But we don't really have to.  We can use square brackets instead, or
we can go back to using parentheses.  This thread suggests that while
clearly some people prefer angle brackets, it is not a dominant
consensus.

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/CAOyqgcVo3d4zrXkGtxPzMUSC%2BJ0ju_B3DsQZj%2B%3D5Ec2%2B3y0%3DSA%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Robert Engels]

This is what I was thinking. Format for the common case. At compile/link time 
you would be able to figure out the conflict and throw an error and the dev 
could add the parens to make it unambiguous. 

> On Jul 15, 2020, at 4:36 PM, Randall O'Reilly  wrote:
> 
> Regarding the parsing: as I suggested in my email, but perhaps was unclear, 
> in case of two conflicting *purely syntactic* interpretations (without using 
> any type information), you could just choose the more high-frequency 
> interpretation (i.e., type parameters) and force the programmer to use 
> additional parens if they actually want the other interpretation.
> 
> So in the case of the example, w < x, y > (z) is *automatically, 
> syntactically* interpreted as a function call using 2 type parameters, and if 
> you want it to be two different relational expressions, you have to wrap them 
> in parens: (w < x), (y > (z))
> 
> This latter use is likely to be vanishingly rare (someone could run their 
> code analysis on it), so this seems like a small inconvenience.  Maybe there 
> are other such conflicts?  If this is the only one, I don't think it is 
> sufficient to rule out the use of < >.
> 
> My mention of the point about gofmt was just that it should get rid of the 
> seemingly redundant extra paren around (z), but I just tried it and 
> apparently it does not, even with gofmt -s.  Anyway, the above point stands: 
> you CAN parse < > correctly by just making purely syntactic choices in the 
> case of conflicts, and this applies to all Go tools using the same purely 
> syntactic parsing pass.
> 
> Also, according to Tiobe, Scala is ranked 39, and whereas C, Java, C++, C#, 
> are all top 10, and the C family is clearly the syntactic heritage of Go.
> 
> And the use of [ ] in map is more semantically associated with its 
> conventional use as an element accessor in arrays / slices, not with some 
> more general kind of type parameter.
> 
> - Randy
> 
>> On Jul 15, 2020, at 11:48 AM, Ian Lance Taylor  wrote:
>> 
>>> On Tue, Jul 14, 2020 at 9:45 PM robert engels  wrote:
>>> 
>>> My opinion is that every major language (no flames please… lots of 
>>> developers write lots of programs and make money doing it) that supports 
>>> generics uses < > for generic types, so Go should too - since there is no 
>>> reason to deviate from this other than to avoid changes to the parser. 
>>> Seems better to pay this cost once - rather than every Go program that uses 
>>> generics being harder to read for eternity (especially for those readers 
>>> that use a lot of languages).
>> 
>> Thanks for the note.
>> 
>> I'll briefly mention, as others have, that Scala successfully uses
>> square brackets for generics, and that in Go the map type already uses
>> square brackets to indicate the generic key type (though the value
>> type is outside the square brackets).  So it's not like this is
>> entirely new ground.
>> 
>> It's also worth noting that the Go survey results
>> (https://blog.golang.org/survey2019-results) show us that the
>> languages most Go programmers are familiar with are Python and
>> JavaScript, which of course do not use generics at all with any sort
>> of brackets.  So the familiarity argument only goes so far.
>> 
>> More seriously, though, let's look closely at Robert's example:
>> 
>> a, b = w < x, y > (z)
>> 
>> When parsing this without any information about what the identifiers
>> mean, this could be either an assignment of two values to two
>> variables:
>> 
>> a = w < x
>> b = y > (z)
>> 
>> or it could be a call of the instantiated function w passing the
>> argument z and returning two results.  By the way, don't get
>> distracted by the parentheses around z, it can be an arbitrary
>> expression, so although (z) might be unusual using parentheses around
>> a more complex expression might be entirely reasonable.
>> 
>> Without knowing the type of w, we can not parse this statement.  This
>> has nothing to do with lookahead or the nature of parsing or anything
>> else.  It's fundamental to the syntax.
>> 
>> In order for tools like gofmt and goimports to be effective and be
>> fast enough to run on file save, they have to be able to parse Go code
>> without knowing types.  In the general case, where w might actually be
>> written as pkg.w, knowing the type of w will require chasing through
>> an arbitrary number of imported packages.  Requiring simple tools like
>> gofmt and goimports to do this kind of type checking would break one
>> of the basic guidelines that Go has followed from the beginning: the
>> language must be easy and fast to parse without knowing types.
>> 
>> I'll note that C++ also has this syntactic problem, and indeed C++
>> cannot be parsed without full type information.  This is part of why
>> tools that work with Go code run much faster than tools that work with
>> C++ code, and is part of why the Go compiler is much faster than
>> typical C++ compilers.
>> 
>> So it's really not a matter of "just fix the 

Re: [go-nuts] Generics and parentheses

[Randall O'Reilly]

Regarding the parsing: as I suggested in my email, but perhaps was unclear, in 
case of two conflicting *purely syntactic* interpretations (without using any 
type information), you could just choose the more high-frequency interpretation 
(i.e., type parameters) and force the programmer to use additional parens if 
they actually want the other interpretation.

So in the case of the example, w < x, y > (z) is *automatically, syntactically* 
interpreted as a function call using 2 type parameters, and if you want it to 
be two different relational expressions, you have to wrap them in parens: (w < 
x), (y > (z))

This latter use is likely to be vanishingly rare (someone could run their code 
analysis on it), so this seems like a small inconvenience.  Maybe there are 
other such conflicts?  If this is the only one, I don't think it is sufficient 
to rule out the use of < >.

My mention of the point about gofmt was just that it should get rid of the 
seemingly redundant extra paren around (z), but I just tried it and apparently 
it does not, even with gofmt -s.  Anyway, the above point stands: you CAN parse 
< > correctly by just making purely syntactic choices in the case of conflicts, 
and this applies to all Go tools using the same purely syntactic parsing pass.

Also, according to Tiobe, Scala is ranked 39, and whereas C, Java, C++, C#, are 
all top 10, and the C family is clearly the syntactic heritage of Go.

And the use of [ ] in map is more semantically associated with its conventional 
use as an element accessor in arrays / slices, not with some more general kind 
of type parameter.

- Randy

> On Jul 15, 2020, at 11:48 AM, Ian Lance Taylor  wrote:
> 
> On Tue, Jul 14, 2020 at 9:45 PM robert engels  wrote:
>> 
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. Seems 
>> better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages).
> 
> Thanks for the note.
> 
> I'll briefly mention, as others have, that Scala successfully uses
> square brackets for generics, and that in Go the map type already uses
> square brackets to indicate the generic key type (though the value
> type is outside the square brackets).  So it's not like this is
> entirely new ground.
> 
> It's also worth noting that the Go survey results
> (https://blog.golang.org/survey2019-results) show us that the
> languages most Go programmers are familiar with are Python and
> JavaScript, which of course do not use generics at all with any sort
> of brackets.  So the familiarity argument only goes so far.
> 
> More seriously, though, let's look closely at Robert's example:
> 
> a, b = w < x, y > (z)
> 
> When parsing this without any information about what the identifiers
> mean, this could be either an assignment of two values to two
> variables:
> 
> a = w < x
> b = y > (z)
> 
> or it could be a call of the instantiated function w passing the
> argument z and returning two results.  By the way, don't get
> distracted by the parentheses around z, it can be an arbitrary
> expression, so although (z) might be unusual using parentheses around
> a more complex expression might be entirely reasonable.
> 
> Without knowing the type of w, we can not parse this statement.  This
> has nothing to do with lookahead or the nature of parsing or anything
> else.  It's fundamental to the syntax.
> 
> In order for tools like gofmt and goimports to be effective and be
> fast enough to run on file save, they have to be able to parse Go code
> without knowing types.  In the general case, where w might actually be
> written as pkg.w, knowing the type of w will require chasing through
> an arbitrary number of imported packages.  Requiring simple tools like
> gofmt and goimports to do this kind of type checking would break one
> of the basic guidelines that Go has followed from the beginning: the
> language must be easy and fast to parse without knowing types.
> 
> I'll note that C++ also has this syntactic problem, and indeed C++
> cannot be parsed without full type information.  This is part of why
> tools that work with Go code run much faster than tools that work with
> C++ code, and is part of why the Go compiler is much faster than
> typical C++ compilers.
> 
> So it's really not a matter of "just fix the parser to use angle
> brackets."  As far as I've been able to tell, using angle brackets is
> technically infeasible, given the way that Go works.  Other languages
> make different choices, and those choices work for them, but this is
> not a choice that Go is able to make.
> 
> So, I hear you: you and many others would prefer angle brackets.  But
> unless and until someone explains how it 

Re: [go-nuts] Generics and parentheses

[Robert Engels]

But Scala doesn’t use [] for anything else - Go does. 

> On Jul 15, 2020, at 9:58 AM, 'Nic Long' via golang-nuts 
>  wrote:
> 
> Square brackets work great. Scala uses them for generics to great effect. 
> They also make me think of Clojure, which introduced them to Lisp for similar 
> reasons to here - to avoid too much overload of regular parentheses - and 
> which people have been very happy with.
> 
>> On Wednesday, 15 July 2020 at 08:37:15 UTC+1 ba...@iitbombay.org wrote:
>> As I wrote, parentheses are not needed for the common case of single type 
>> parameter. If you have more than one, you need parentheses but note that 
>> this 
>> is a *prefix* and any parsing ambiguities can removed by using a - if 
>> needed. 
>> For your example it will be something like 
>> 
>> (float64,int)PowN(1.2, 3) 
>> 
>> It’s just a syntax change. There is zero semantic difference from the 
>> current 
>> proposal. I just tried to get idea across - I can work out a complete set of 
>> syntax rule changes if there is sufficient interest but the gen rule will be 
>> something like 
>> 
>> gen-type-decl: gen-prefix type-decl; 
>> gen-func-decl: gen-prefix func-decl; 
>> gen-prefix: “gen” typeX-list 
>> typeX-list: typeX | typeX-list “,” typeX ; 
>> typeX: NAME [constraint] ; 
>> 
>> > On Jul 15, 2020, at 12:01 AM, 'Dan Kortschak' via golang-nuts 
>> >  wrote: 
>> > 
>> > How do these deal with non-type determined uses. Say you have (by any 
>> > spelling) 
>> > 
>> > gen F,I func PowN(a F, b I) F {...} 
>> > 
>> > How do you specify the type of F or I when say you have untyped 
>> > constants. This still requires parens or other markings to indicate the 
>> > actual types of F and I. It seems many of the comments here complaining 
>> > about brackets and such are ignoring this aspect of the current 
>> > proposal. 
> 
> This e-mail and all attachments are confidential and may also be privileged. 
> If you are not the named recipient, please notify the sender and delete the 
> e-mail and all attachments immediately. Do not disclose the contents to 
> another person. You may not use the information for any purpose, or store, or 
> copy, it in any way.  Guardian News & Media Limited is not liable for any 
> computer viruses or other material transmitted with or as part of this 
> e-mail. You should employ virus checking software.
>  
> Guardian News & Media Limited is a member of Guardian Media Group plc. 
> Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  
> Registered in England Number 908396
> 
> 
> -- 
> 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/9ac6d86f-7647-4814-b15f-67f5cec5dadcn%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/FBC26216-66EC-4EE8-8721-A907729FBB81%40ix.netcom.com.

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

On Wed, Jul 15, 2020 at 5:44 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> My 2c - Alternative type parameters syntax (ab)using @$:
> https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing

Thanks for the detailed writeup.  I'm a bit concerned about name
scoping.  Also about the fact that constraints can apparently show up
anywhere; is that always going to work?  And I don't think that
Vector@$T is going to be all that intuitive for anybody to read.

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

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah  wrote:
>
> I don't much like square brackets or angle brackets or guillemets. But here 
> is a different way
> of reducing the need for parentheses at least for the common case:
>
> A proposal for fewer irritating parentheses!
>
> One thing to note is that generic functions & types are *different* from
> existing things like const, func, type, var. As such they should have their
> own declaration marker. For example
>
> gen T   type pair struct { a, b T } // contrast with type pair(type T) ...
> gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ...
> gen T   func Print(s []T) {...} // print a slice of T
>
> These function/type/method generics are used by *prepending* the type:
>
> var x int pair // a pair of ints
> var y (int, int pair) W // here we have to use parentheses
> int Print([]int{1,2,3}) // print a slice of ints
> qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
> ww := (int, int) W pair{{1,2},{3,4}}
>
> This use may seem weird if you are used to C/C++. I find it more readable
> than having to deal with extra parentheses. "int pair" clearly says a
> pair of ints and so on. What is more, if in future types are allowed to be
> *inferred* for generic function calls, you can simply drop the type prefix.
>
> If there is still a parsing ambiguity, I'd suggest adding a - as in int-pair.
>
> Additional type syntax rule:
>
> type: ... | type generic-type| (type-list) generic-type
>
> or
>
> type: ... | type "-" generic-type | (type-list) "-" generic-type
>
> FWIW I thought of this four weeks ago (June 16).


Thanks for the note.  It's an interesting idea, but I'm not quite sure
it works to have prefix types with no real delimiters.  It may work to
write "int pair pair" but does it work to write "func() int pair
pair"?  That is the type of a pair of functions where each function
returns the type "int pair".  If we have to start carefully deciding
where we need to add parentheses then I'm not sure we've gained very
much by switching to this kind of syntax.

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/CAOyqgcWf8KaJdHgq2fccEAZU_KNAx92G--VvEeJT-fr2ZMCnbw%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[David Riley]

On Jul 15, 2020, at 2:48 PM, Ian Lance Taylor  wrote:
> 
> More seriously, though, let's look closely at Robert's example:
> 
> a, b = w < x, y > (z)

TBH, I think a big argument in favor of square brackets over angle brackets is 
that they ascend above the center line in most typefaces, which makes them much 
more visually distinct from the shorter operators and many lowercase letters.  
This is similar to parens and curly braces while still being visually distinct 
from both.

As something that is essentially a metaparameter which is similar to, but 
distinct in function to the arguments in parens, there's a lot of good 
consistency going on there that I personally find easier to visually scan 
without syntax highlighting than I do angle brackets.  But that could be just 
me, and it does depend on typeface, so take it with whatever grains of salt you 
need to.


- 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/51B8F207-955C-4C9C-88C6-A0FD605C6ACA%40gmail.com.

Re: [go-nuts] Generics and parentheses

[Seebs]

On Wed, 15 Jul 2020 12:26:15 -0700
Ian Lance Taylor  wrote:

> The suggested syntax, whether with parentheses or square brackets, has
> what I consider to be a very nice property: the definition and use
> syntaxes are very similar.  For the definition we write
> 
> func F[type T]() {}
> 
> For the use we write
> 
> F[int]()
> 
> The two aren't identical, but the syntax is parallel.

Maybe the "type" should be required in both? That feels annoying and
ugly, but it would eliminate any possible ambiguity about how to
interpret the name in the []:

var F1 []func()
F1[otherpkg.Y]()
func F2[type T]() {}
F2[otherpkg.Z]()

-s

-- 
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/20200715145841.7eb04b59%40seebsdell.

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

On Tue, Jul 14, 2020 at 10:06 PM Paul Johnston  wrote:
>
> If the generic expression  was always attached/constrained to the "type" 
> or "func" keyword (rather than the type or function name), perhaps this would 
> decrease the lookahead problems with lexing?  For example:
>
> type Point struct {
> x, y int
> data T
> }
>
> type Transformer interface {
> Transform(R) S
> }
>
> func Stringify(s []T) string {
> }
>
> type Vector []T

Well, you need to consider not just the definitions, but also the uses.

The suggested syntax, whether with parentheses or square brackets, has
what I consider to be a very nice property: the definition and use
syntaxes are very similar.  For the definition we write

func F[type T]() {}

For the use we write

F[int]()

The two aren't identical, but the syntax is parallel.

The same is true in Java.  Admittedly in C++ the syntaxes are not
parallel, and are more like what you suggest.

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/CAOyqgcXQRpYJw%3DO%3DFp-jSJrUrD08A1FYwMBUE1OVc4yskyud6g%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Hein Meling]

Correction: I think it is much more important that Go remains internally 
consistent in its use of "square" brackets.

On Wednesday, July 15, 2020 at 8:54:58 PM UTC+2 Hein Meling wrote:

> When you refer to beginners, I think you mean developers from other 
> languages (Java/C#/C++...) that already know the concept of generics. I 
> don't think they will have problems adapting to a square brackets 
> notation... they are smart people, and after all they have to learn many 
> other syntactical differences as well, so one more difference is not going 
> to be the deal breaker. And if they make , the compiler will 
> [surely] tell them ;-)
>
> In fact, the square bracket notation is already adopted for declaring the 
> type of maps and slices. So switching to angle brackets will make Go's 
> generics implementation internally inconsistent, since you must declare a 
> map[string]int with angle brackets and then elsewhere, you will be using 
>  for the same concept. I think it is much more important that Go 
> remains internally consistent in its use of angle brackets.
>
> Best,
> :) Hein
>
>
>
> On Wednesday, July 15, 2020 at 7:03:40 PM UTC+2 dmar...@gmail.com wrote:
>
>> On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels wrote:
>>>
>>> My opinion is that every major language (no flames please… lots of 
>>> developers write lots of programs and make money doing it) that supports 
>>> generics uses < > for generic types, so Go should too - since there is no 
>>> reason to deviate from this other than to avoid changes to the parser. 
>>> Seems better to pay this cost once - rather than every Go program that uses 
>>> generics being harder to read for eternity (especially for those readers 
>>> that use a lot of languages). 
>>>
>>
>> This really captures my feeling perfectly, the parser changes have to be 
>> less man hours to build and maintain going forward than the man hours of 
>> all the existing and new developers. All options have a downsides at least 
>>  is as "standard" as one can get when talking about  generics. 
>>
>> Some version of  will help beginners in reducing the cognitive load 
>> when learning and using Go.  
>>
>> Thanks,
>> -Dan 
>>  
>>
>>  
>>
>>> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  
>>> wrote: 
>>> > 
>>> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>>> wrote: 
>>> >> 
>>> >> This feels a little better, but honestly I'm still all for angle 
>>> brackets or like Watson suggested, guillamets. 
>>> >> 
>>> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 
>>> >> fn[T1](fn2[T2](fn3[T3](v))) // 2 
>>> >> fn(fn2(fn3(v))) // 3 
>>> >> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4 
>>> >> 
>>> >> To me, with a background in C++ and Typescript and a little bit of 
>>> Rust, #3 and #4 are just natural and easier to read. 
>>> > 
>>>
>> > The advantage of parentheses is that the language already uses 
>>> > parentheses for lists in various places.  Of course that is also the 
>>> > disadvantage. 
>>> > 
>>> > When considering something other than parentheses, I encourage people 
>>> > to look for objective reasons why one syntax is better than another. 
>>> > It's going to be different from other aspects of the language.  So 
>>> > what reason would we have for preferring one syntax over another? 
>>> > 
>>> > For example: 
>>> > 
>>> > Robert already gave reasons why square brackets are better than angle 
>>> brackets. 
>>> > 
>>> > The disadvantage of guillemets is that they are hard to type on many 
>>> > keyboards.  So to me either square brackets or angle brackets would be 
>>> > better than guillemets. 
>>> > 
>>> > The disadvantage of a two character sequence such as <: :> is that it 
>>> > is more typing.  So again either square brackets or angle brackets 
>>> > seem to me to be better. 
>>> > 
>>> > An example of a reason that square brackets might be a poor choice 
>>> > would be ambiguous parsing, or cases where the code is harder to read. 
>>> > 
>>> > It's true that some other languages use angle brackets, but Go already 
>>> > does many things differently.  That is only a minor advantage for 
>>> > angle brackets.  To me at least it does not outweigh the 
>>> > disadvantages. 
>>> > 
>>> > In short, please try to provide reasons for a different syntax.  "It 
>>> > looks good" is a valid reason, but please try to explain why it looks 
>>> > better than square brackets or parentheses. 
>>> > 
>>> > Thanks. 
>>> > 
>>> > Ian 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group. 
>>>
>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golan...@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 

Re: [go-nuts] Generics and parentheses

[Hein Meling]

When you refer to beginners, I think you mean developers from other 
languages (Java/C#/C++...) that already know the concept of generics. I 
don't think they will have problems adapting to a square brackets 
notation... they are smart people, and after all they have to learn many 
other syntactical differences as well, so one more difference is not going 
to be the deal breaker. And if they make , the compiler will 
[surely] tell them ;-)

In fact, the square bracket notation is already adopted for declaring the 
type of maps and slices. So switching to angle brackets will make Go's 
generics implementation internally inconsistent, since you must declare a 
map[string]int with angle brackets and then elsewhere, you will be using 
 for the same concept. I think it is much more important that Go 
remains internally consistent in its use of angle brackets.

Best,
:) Hein



On Wednesday, July 15, 2020 at 7:03:40 PM UTC+2 dmar...@gmail.com wrote:

> On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels wrote:
>>
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. 
>> Seems better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages). 
>>
>
> This really captures my feeling perfectly, the parser changes have to be 
> less man hours to build and maintain going forward than the man hours of 
> all the existing and new developers. All options have a downsides at least 
>  is as "standard" as one can get when talking about  generics. 
>
> Some version of  will help beginners in reducing the cognitive load 
> when learning and using Go.  
>
> Thanks,
> -Dan 
>  
>
>  
>
>> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  
>> wrote: 
>> > 
>> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>> wrote: 
>> >> 
>> >> This feels a little better, but honestly I'm still all for angle 
>> brackets or like Watson suggested, guillamets. 
>> >> 
>> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 
>> >> fn[T1](fn2[T2](fn3[T3](v))) // 2 
>> >> fn(fn2(fn3(v))) // 3 
>> >> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4 
>> >> 
>> >> To me, with a background in C++ and Typescript and a little bit of 
>> Rust, #3 and #4 are just natural and easier to read. 
>> > 
>>
> > The advantage of parentheses is that the language already uses 
>> > parentheses for lists in various places.  Of course that is also the 
>> > disadvantage. 
>> > 
>> > When considering something other than parentheses, I encourage people 
>> > to look for objective reasons why one syntax is better than another. 
>> > It's going to be different from other aspects of the language.  So 
>> > what reason would we have for preferring one syntax over another? 
>> > 
>> > For example: 
>> > 
>> > Robert already gave reasons why square brackets are better than angle 
>> brackets. 
>> > 
>> > The disadvantage of guillemets is that they are hard to type on many 
>> > keyboards.  So to me either square brackets or angle brackets would be 
>> > better than guillemets. 
>> > 
>> > The disadvantage of a two character sequence such as <: :> is that it 
>> > is more typing.  So again either square brackets or angle brackets 
>> > seem to me to be better. 
>> > 
>> > An example of a reason that square brackets might be a poor choice 
>> > would be ambiguous parsing, or cases where the code is harder to read. 
>> > 
>> > It's true that some other languages use angle brackets, but Go already 
>> > does many things differently.  That is only a minor advantage for 
>> > angle brackets.  To me at least it does not outweigh the 
>> > disadvantages. 
>> > 
>> > In short, please try to provide reasons for a different syntax.  "It 
>> > looks good" is a valid reason, but please try to explain why it looks 
>> > better than square brackets or parentheses. 
>> > 
>> > Thanks. 
>> > 
>> > Ian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group. 
>>
> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to golan...@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/c2c831e5-cdd3-4602-901f-53f927b2ab12n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Ian Lance Taylor]

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

Thanks for the note.

I'll briefly mention, as others have, that Scala successfully uses
square brackets for generics, and that in Go the map type already uses
square brackets to indicate the generic key type (though the value
type is outside the square brackets).  So it's not like this is
entirely new ground.

It's also worth noting that the Go survey results
(https://blog.golang.org/survey2019-results) show us that the
languages most Go programmers are familiar with are Python and
JavaScript, which of course do not use generics at all with any sort
of brackets.  So the familiarity argument only goes so far.

More seriously, though, let's look closely at Robert's example:

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

When parsing this without any information about what the identifiers
mean, this could be either an assignment of two values to two
variables:

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

or it could be a call of the instantiated function w passing the
argument z and returning two results.  By the way, don't get
distracted by the parentheses around z, it can be an arbitrary
expression, so although (z) might be unusual using parentheses around
a more complex expression might be entirely reasonable.

Without knowing the type of w, we can not parse this statement.  This
has nothing to do with lookahead or the nature of parsing or anything
else.  It's fundamental to the syntax.

In order for tools like gofmt and goimports to be effective and be
fast enough to run on file save, they have to be able to parse Go code
without knowing types.  In the general case, where w might actually be
written as pkg.w, knowing the type of w will require chasing through
an arbitrary number of imported packages.  Requiring simple tools like
gofmt and goimports to do this kind of type checking would break one
of the basic guidelines that Go has followed from the beginning: the
language must be easy and fast to parse without knowing types.

I'll note that C++ also has this syntactic problem, and indeed C++
cannot be parsed without full type information.  This is part of why
tools that work with Go code run much faster than tools that work with
C++ code, and is part of why the Go compiler is much faster than
typical C++ compilers.

So it's really not a matter of "just fix the parser to use angle
brackets."  As far as I've been able to tell, using angle brackets is
technically infeasible, given the way that Go works.  Other languages
make different choices, and those choices work for them, but this is
not a choice that Go is able to make.

So, I hear you: you and many others would prefer angle brackets.  But
unless and until someone explains how it could be done, we must
continue to regard that choice as off the table.

Sorry.

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

Re: [go-nuts] Generics and parentheses

[Zippoxer]

Agreed. I've been a happy Gopher since 2011 and would really like to see <> 
or even [] instead of ().

On Wednesday, 15 July 2020 20:03:40 UTC+3, Dan Markham wrote:
>
> On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels wrote:
>>
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. 
>> Seems better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages). 
>>
>
> This really captures my feeling perfectly, the parser changes have to be 
> less man hours to build and maintain going forward than the man hours of 
> all the existing and new developers. All options have a downsides at least 
>  is as "standard" as one can get when talking about  generics. 
>
> Some version of  will help beginners in reducing the cognitive load 
> when learning and using Go.  
>
> Thanks,
> -Dan 
>  
>
>  
>
>> > On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  
>> wrote: 
>> > 
>> > On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>> wrote: 
>> >> 
>> >> This feels a little better, but honestly I'm still all for angle 
>> brackets or like Watson suggested, guillamets. 
>> >> 
>> >> fn(T1)(fn2(T2)(fn3(T3)(v))) // 1 
>> >> fn[T1](fn2[T2](fn3[T3](v))) // 2 
>> >> fn(fn2(fn3(v))) // 3 
>> >> fn«T1»(fn2«T2»(fn3«T3»v)))  // 4 
>> >> 
>> >> To me, with a background in C++ and Typescript and a little bit of 
>> Rust, #3 and #4 are just natural and easier to read. 
>> > 
>> > The advantage of parentheses is that the language already uses 
>> > parentheses for lists in various places.  Of course that is also the 
>> > disadvantage. 
>> > 
>> > When considering something other than parentheses, I encourage people 
>> > to look for objective reasons why one syntax is better than another. 
>> > It's going to be different from other aspects of the language.  So 
>> > what reason would we have for preferring one syntax over another? 
>> > 
>> > For example: 
>> > 
>> > Robert already gave reasons why square brackets are better than angle 
>> brackets. 
>> > 
>> > The disadvantage of guillemets is that they are hard to type on many 
>> > keyboards.  So to me either square brackets or angle brackets would be 
>> > better than guillemets. 
>> > 
>> > The disadvantage of a two character sequence such as <: :> is that it 
>> > is more typing.  So again either square brackets or angle brackets 
>> > seem to me to be better. 
>> > 
>> > An example of a reason that square brackets might be a poor choice 
>> > would be ambiguous parsing, or cases where the code is harder to read. 
>> > 
>> > It's true that some other languages use angle brackets, but Go already 
>> > does many things differently.  That is only a minor advantage for 
>> > angle brackets.  To me at least it does not outweigh the 
>> > disadvantages. 
>> > 
>> > In short, please try to provide reasons for a different syntax.  "It 
>> > looks good" is a valid reason, but please try to explain why it looks 
>> > better than square brackets or parentheses. 
>> > 
>> > Thanks. 
>> > 
>> > Ian 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "golang-nuts" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to golan...@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/99edaa65-798c-4870-bb15-0a43bbe6c868o%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Dan Markham]

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

This really captures my feeling perfectly, the parser changes have to be 
less man hours to build and maintain going forward than the man hours of 
all the existing and new developers. All options have a downsides at least 
 is as "standard" as one can get when talking about  generics. 

Some version of  will help beginners in reducing the cognitive load when 
learning and using Go.  

Thanks,
-Dan 
 

 

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

Re: [go-nuts] Generics and parentheses

[Seebs]

On Tue, 14 Jul 2020 23:19:40 -0700 (PDT)
Fino  wrote:

> I vote for <: and :> 

I'm conflicted on it. <> match what several other languages do, but are
problematic for the parser. () is definitely overused. [] is tolerable.

I'd like to bring up the possibility of ??( and ??), mostly so that
whatever we end up with, people will be able to say "well, at least it
wasn't trigraphs".

-s

-- 
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/20200715100851.75263e50%40seebsdell.

Re: [go-nuts] Generics and parentheses

[Tao Liu]

This is similar to C++ template,  and it's very clear to understand. 

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/31376715-50f1-450f-b8ad-12f02fbc05d2o%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

['Nic Long' via golang-nuts]

Square brackets work great. Scala uses them for generics to great effect. 
They also make me think of Clojure, which introduced them to Lisp for 
similar reasons to here - to avoid too much overload of regular parentheses 
- and which people have been very happy with.

On Wednesday, 15 July 2020 at 08:37:15 UTC+1 ba...@iitbombay.org wrote:

> As I wrote, parentheses are not needed for the common case of single type
> parameter. If you have more than one, you need parentheses but note that 
> this
> is a *prefix* and any parsing ambiguities can removed by using a - if 
> needed.
> For your example it will be something like
>
> (float64,int)PowN(1.2, 3)
>
> It’s just a syntax change. There is zero semantic difference from the 
> current
> proposal. I just tried to get idea across - I can work out a complete set 
> of
> syntax rule changes if there is sufficient interest but the gen rule will 
> be
> something like
>
> gen-type-decl: gen-prefix type-decl;
> gen-func-decl: gen-prefix func-decl;
> gen-prefix: “gen” typeX-list
> typeX-list: typeX | typeX-list “,” typeX ;
> typeX: NAME [constraint] ;
>
> > On Jul 15, 2020, at 12:01 AM, 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com> wrote:
> > 
> > How do these deal with non-type determined uses. Say you have (by any
> > spelling)
> > 
> > gen F,I func PowN(a F, b I) F {...}
> > 
> > How do you specify the type of F or I when say you have untyped
> > constants. This still requires parens or other markings to indicate the
> > actual types of F and I. It seems many of the comments here complaining
> > about brackets and such are ignoring this aspect of the current
> > proposal.
>

-- 

This e-mail and all attachments are confidential and may also be 
privileged. If you are not the named recipient, please notify the sender 
and delete the e-mail and all attachments immediately. Do not disclose the 
contents to another person. You may not use the information for any 
purpose, or store, or copy, it in any way.  Guardian News & Media Limited 
is not liable for any computer viruses or other material transmitted with 
or as part of this e-mail. You should employ virus checking software.
 

Guardian News & Media Limited is a member of Guardian Media Group plc. 
Registered Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP. 
 Registered in England Number 908396




-- 
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/9ac6d86f-7647-4814-b15f-67f5cec5dadcn%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[David Riley]

On Jul 15, 2020, at 4:47 AM, Nick Craig-Wood  wrote:
> 
> In my mind the use of [ ]  clashes horribly with the array declaration 
> syntax. When I see [int] in particular my brain says, ah array declaration of 
> size int, what, no wait...

On the other hand, this is already how maps are declared (e.g. map[int]string). 
It's fairly consistent with that, actually.


- 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/A93735EA-52DB-4505-BF8F-4BFD22CC0D73%40gmail.com.

Re: [go-nuts] Generics and parentheses

[Jan Mercl]

On Tue, Jul 14, 2020 at 11:55 PM 'Robert Griesemer' via golang-nuts
 wrote:

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

My 2c - Alternative type parameters syntax (ab)using @$:
https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing

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

Re: [go-nuts] Generics and parentheses

[Jesper Louis Andersen]

On Wed, Jul 15, 2020 at 11:27 AM Randall O'Reilly 
wrote:

> wouldn't gofmt remove the superfluous (z) in this case (and even with a
> more complex expression inside the parens, as the > operator would have
> appropriate precedence?), in existing code?  And thus, would it not be
> reasonable to have a convention in this case that if you have an expression
> that fits the type parameter interpretation, that interpretation is used
> instead of the alternative?  And if you really wanted to write the
> alternative, you would be forced to make it explicit with the parens as
> noted:
>
> a, b = (w < x), (y > (z))
>
> This seems like a very rare case, and a small price to pay for following
> the established convention..
>
>
If the parser cannot disambiguate without type information, then neither
can gofmt.

In practice, this means you risk opening pandoras box in several ways:

* gofmt is now part of the system, as you cannot safely parse without it.
* gofmt needs to be more powerful than the parser.
* gofmt must alter the semantics of the program, which goes directly
against the idea of gofmt.

The really hard part is that you have to nail all parsing problems in a
parser. You can't attack problems on a case-by-case basis as it often
yields inconsistency.

Languages in the ML family solves problems like the above by having several
steps in the chain:

Lex -> Parse -> Elaborate -> Phase split -> Type Check -> ... -> Machine
code

Elaboration is the phase where type information is brought in to
disambiguate what the parser found. Phase splitting is also interesting in
that it splits work into compile-time and runtime phases (since MLs kind of
blends those two things together in its syntax). However, this has
implications in the complexity of the parser and language. Go seems to lean
more toward a Niklaus Wirth'esque simplicity path; though not as stringent
as Wirth would.

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

Re: [go-nuts] Generics and parentheses

[Randall O'Reilly]

Sorry to perseverate and belabor the point, but here's an analogy that makes 
the point perhaps more strongly and succinctly:

Imagine that, for some reason, Go didn't have the array/slice element operator 
syntax, [ ], and it was now going to be introduced in Go2, but instead of using 
this established existing convention, parens were going to be used instead of [ 
], due to some parser considerations.  I suspect many people would feel the 
same way they feel about the < > syntax: this is such an established convention 
that it would seem crazy to not adopt it.

If other languages can get their parsers to deal with this syntax, why not Go?  
Certainly fast parsing is an important feature, but if anything, readability is 
perhaps even more important than that?

And to specifically address the example from the original email:

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

wouldn't gofmt remove the superfluous (z) in this case (and even with a more 
complex expression inside the parens, as the > operator would have appropriate 
precedence?), in existing code?  And thus, would it not be reasonable to have a 
convention in this case that if you have an expression that fits the type 
parameter interpretation, that interpretation is used instead of the 
alternative?  And if you really wanted to write the alternative, you would be 
forced to make it explicit with the parens as noted:

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

This seems like a very rare case, and a small price to pay for following the 
established convention..

- Randy

> On Jul 14, 2020, at 11:53 PM, Randall O'Reilly  wrote:
> 
> Tagging onto this point: while Go deviates from other languages in a number 
> of important ways, syntax at the level of things like parens, brackets, etc 
> is not one of these key differences.  It is almost entirely consistent with 
> the "de facto" C-style choices in this respect (to the extent that people 
> mistakenly regard it as just a subset of C).  In this context, it does seem a 
> bit of "being different for its own sake", to adopt something *other* than 
> the < > convention for generic types.
> 
> Yes, Go should boldly Go where no language has gone before^*, but when it is 
> basically adopting a well-established paradigm widely used in existing 
> languages, doesn't it also make sense to adopt the well-established syntax 
> associated with that paradigm? (although the proposed Go generics differ in 
> some important ways from other languages, the use of type parameters is not 
> one of them.)
> 
> While we've been asked to focus on the more "objective" facts of parsing 
> considerations here, the above logic would suggest a different approach: if 
> there is any way to adopt the established conventional syntax and make the 
> parsing work, then that is what should be done.  So, essentially, this puts 
> the onus back on the parser programmers to definitively *rule out* the use of 
> < > -- is it really that difficult / costly to do a bit of look-ahead and 
> disambiguate the different use cases? 
> 
> - Randy
> 
> * e.g., see https://github.com/golang/go/issues/39669 for a more radical 
> departure from convention, doing away with the extra parens entirely.
> 
>> On Jul 14, 2020, at 9:45 PM, robert engels  wrote:
>> 
>> My opinion is that every major language (no flames please… lots of 
>> developers write lots of programs and make money doing it) that supports 
>> generics uses < > for generic types, so Go should too - since there is no 
>> reason to deviate from this other than to avoid changes to the parser. Seems 
>> better to pay this cost once - rather than every Go program that uses 
>> generics being harder to read for eternity (especially for those readers 
>> that use a lot of languages).
>> 
>>> On Jul 14, 2020, at 11:13 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Jul 14, 2020 at 8:21 PM Ahmed (OneOfOne) W.  
>>> wrote:
 
 This feels a little better, but honestly I'm still all for angle brackets 
 or like Watson suggested, guillamets.
 
 fn(T1)(fn2(T2)(fn3(T3)(v))) // 1
 fn[T1](fn2[T2](fn3[T3](v))) // 2
 fn(fn2(fn3(v))) // 3
 fn«T1»(fn2«T2»(fn3«T3»v)))  // 4
 
 To me, with a background in C++ and Typescript and a little bit of Rust, 
 #3 and #4 are just natural and easier to read.
>>> 
>>> The advantage of parentheses is that the language already uses
>>> parentheses for lists in various places.  Of course that is also the
>>> disadvantage.
>>> 
>>> When considering something other than parentheses, I encourage people
>>> to look for objective reasons why one syntax is better than another.
>>> It's going to be different from other aspects of the 

Re: [go-nuts] Generics and parentheses

[Jesper Louis Andersen]

On Wed, Jul 15, 2020 at 10:47 AM Nick Craig-Wood 
wrote:

> In my mind the use of [ ]  clashes horribly with the array declaration
> syntax. When I see [int] in particular my brain says, ah array declaration
> of size int, what, no wait...
>
> This makes [identifier] mean two different things depending on whether
> indentifier is a const integer or whether identifier is a type. I think the
> suffix Vs prefix makes it unambiguous but I'm not sure.
>
>
You could make roughly the same argument in a lot of places in the
language, e.g.:

The use of () clashes horribly with the expression declaration syntax. When
I see f(x) in particular, my brain says, "ah! An expression!, what, no
wait!"

This makes (Expr) mean two different things depending on whether it is used
to disambiguate the expression AST or in a function call!

-- 
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/CAGrdgiVJxJcdLyJ55xkEc3jh%3D%3DF4p5zFSn8_Z1BcE%2BBsK3DV8w%40mail.gmail.com.

Re: [go-nuts] Generics and parentheses

[Jesper Louis Andersen]

On Wed, Jul 15, 2020 at 8:25 AM Michael Jones 
wrote:

> nice. "gen" here is akin to the existing forward declaration of recursive
> inner functions. it says, "you are about to see something special and you
> need to know *this* about it."
>
>
The real name is "forall", and it presents a binding site of a type-level
parameter.

  forall T, type pair struct { a, b T }

This would bring the notation close to Coq.

Other solutions:

Haskell used capitalized types, String, Bool, Int, ... and lowercase names
are parameters, so if you used e.g., 't' in the above, it would implicitly
be a type parameter. This is out in Go, due to the capitalization already
being used.

OCaml and SML uses a quote prefix to notion the parameter, e.g., the above
would be written

type 'a pair = { a : 'a; b : 'a }

and likewise

type 'a option = None | Some of 'a

Yet the current proposal is fine! I think keeping the parser simple is an
important goal. Solutions which have whitespace-aware parsing are not good
solutions, I think, because they break that the graphical characters are
the only which have meaning. They also break in subtle ways when you
copy-paste code, some times without parse error but different semantics.
Solutions based on < and > irks me for the lookahead needed in the parser.
That notation was popularized by C++, and I think the argument that we
should just copy it is weak. Go already cleaned up lots of small mistakes
in the C-like syntax. If we can clean up type-level parametrization in
addition, it would be really nice. We can't get any language evolution if
people keep being syntax-conservative. New syntax doesn't automatically
apply a gaussian blur to your eyes.

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

[go-nuts] Generics and parentheses

[Nick Craig-Wood]

In my mind the use of [ ]  clashes horribly with the array declaration syntax. 
When I see [int] in particular my brain says, ah array declaration of size int, 
what, no wait...

This makes [identifier] mean two different things depending on whether 
indentifier is a const integer or whether identifier is a type. I think the 
suffix Vs prefix makes it unambiguous but I'm not sure.

I expect I'd get used to it, but I can see this being difficult for beginners.

-- 
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/8c37b668-5b4c-41fc-aac1-e8876901ff2bo%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Bakul Shah]

As I wrote, parentheses are not needed  for the common case of single type
parameter. If you have more than one, you need parentheses but note that this
is a *prefix* and any parsing ambiguities can removed by using  a - if needed.
For your example it will be something like

(float64,int)PowN(1.2, 3)

It’s just a syntax change. There is zero semantic difference from the current
proposal. I just tried to get idea across - I can work out a complete set of
syntax rule changes if there is sufficient interest but the gen rule will be
something like

gen-type-decl: gen-prefix type-decl;
gen-func-decl: gen-prefix func-decl;
gen-prefix: “gen” typeX-list
typeX-list: typeX | typeX-list “,” typeX ;
typeX: NAME [constraint] ;

> On Jul 15, 2020, at 12:01 AM, 'Dan Kortschak' via golang-nuts 
>  wrote:
> 
> How do these deal with non-type determined uses. Say you have (by any
> spelling)
> 
> gen F,I func PowN(a F, b I) F {...}
> 
> How do you specify the type of F or I when say you have untyped
> constants. This still requires parens or other markings to indicate the
> actual types of F and I. It seems many of the comments here complaining
> about brackets and such are ignoring this aspect of the current
> proposal.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/A7BB89C9-ADDC-4C25-B8DE-EC0F358B5D33%40iitbombay.org.

Re: [go-nuts] Generics and parentheses

['Dan Kortschak' via golang-nuts]

On Tue, 2020-07-14 at 23:53 -0700, Randall O'Reilly wrote:
> So, essentially, this puts the onus back on the parser programmers to
> definitively *rule out* the use of < > -- is it really that difficult
> / costly to do a bit of look-ahead and disambiguate the different use
> cases?

The absence of arbitrary look-ahead was from memory one of the early
design intentions of the language.


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

Re: [go-nuts] Generics and parentheses

['Dan Kortschak' via golang-nuts]

On Tue, 2020-07-14 at 23:05 -0700, Bakul Shah wrote:
> I don't much like square brackets or angle brackets or guillemets.
> But here is a different way
> of reducing the need for parentheses at least for the common case:
> 
> A proposal for fewer irritating parentheses!
> 
> One thing to note is that generic functions & types are *different*
> from
> existing things like const, func, type, var. As such they should have
> their
> own declaration marker. For example
> 
>   gen T   type pair struct { a, b T } // contrast with type
> pair(type T) ...
>   gen T,U type W struct { a T; b U }  // contrast with type
> W(type T, U) ...
>   gen T   func Print(s []T) {...} // print a slice of T
> 
> These function/type/method generics are used by *prepending* the
> type:
> 
>   var x int pair  // a pair of ints
>   var y (int, int pair) W // here we have to use parentheses
>   int Print([]int{1,2,3}) // print a slice of ints
>   qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
>   ww := (int, int) W pair{{1,2},{3,4}}
> 
> This use may seem weird if you are used to C/C++. I find it more
> readable
> than having to deal with extra parentheses. "int pair" clearly says a
> pair of ints and so on. What is more, if in future types are allowed
> to be
> *inferred* for generic function calls, you can simply drop the type
> prefix.
> 
> If there is still a parsing ambiguity, I'd suggest adding a - as in
> int-pair.
> 
> Additional type syntax rule:
> 
>   type: ... | type generic-type| (type-list) generic-type
> 
> or
> 
>   type: ... | type "-" generic-type | (type-list) "-" generic-
> type
> 
> FWIW I thought of this four weeks ago (June 16).
> 

How do these deal with non-type determined uses. Say you have (by any
spelling)

gen F,I func PowN(a F, b I) F {...}

How do you specify the type of F or I when say you have untyped
constants. This still requires parens or other markings to indicate the
actual types of F and I. It seems many of the comments here complaining
about brackets and such are ignoring this aspect of the current
proposal.


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

Re: [go-nuts] Generics and parentheses

[Randall O'Reilly]

Tagging onto this point: while Go deviates from other languages in a number of 
important ways, syntax at the level of things like parens, brackets, etc is not 
one of these key differences.  It is almost entirely consistent with the "de 
facto" C-style choices in this respect (to the extent that people mistakenly 
regard it as just a subset of C).  In this context, it does seem a bit of 
"being different for its own sake", to adopt something *other* than the < > 
convention for generic types.

Yes, Go should boldly Go where no language has gone before^*, but when it is 
basically adopting a well-established paradigm widely used in existing 
languages, doesn't it also make sense to adopt the well-established syntax 
associated with that paradigm? (although the proposed Go generics differ in 
some important ways from other languages, the use of type parameters is not one 
of them.)

While we've been asked to focus on the more "objective" facts of parsing 
considerations here, the above logic would suggest a different approach: if 
there is any way to adopt the established conventional syntax and make the 
parsing work, then that is what should be done.  So, essentially, this puts the 
onus back on the parser programmers to definitively *rule out* the use of < > 
-- is it really that difficult / costly to do a bit of look-ahead and 
disambiguate the different use cases? 

- Randy

* e.g., see https://github.com/golang/go/issues/39669 for a more radical 
departure from convention, doing away with the extra parens entirely.

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

-- 
You received this message because you are subscribed to the Google Groups 

Re: [go-nuts] Generics and parentheses

[Michael Jones]

nice. "gen" here is akin to the existing forward declaration of recursive
inner functions. it says, "you are about to see something special and you
need to know *this* about it."

On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah  wrote:

> I don't much like square brackets or angle brackets or guillemets. But
> here is a different way
> of *reducing* the need for parentheses at least for the common case:
>
> A proposal for fewer irritating parentheses!
>
> One thing to note is that generic functions & types are *different* from
> existing things like const, func, type, var. As such they should have their
> own declaration marker. For example
>
> gen T   type pair struct { a, b T } // contrast with type pair(type T) ...
> gen T,U type W struct { a T; b U } // contrast with type W(type T, U) ...
> gen T   func Print(s []T) {...} // print a slice of T
>
> These function/type/method generics are used by *prepending* the type:
>
> var x int pair // a pair of ints
> var y (int, int pair) W // here we have to use parentheses
> int Print([]int{1,2,3}) // print a slice of ints
> qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
> ww := (int, int) W pair{{1,2},{3,4}}
>
> This use may seem weird if you are used to C/C++. I find it more readable
> than having to deal with extra parentheses. "int pair" clearly says a
> pair of ints and so on. What is more, if in future types are allowed to be
> *inferred* for generic function calls, you can simply drop the type prefix.
>
> If there is still a parsing ambiguity, I'd suggest adding a - as in
> int-pair.
>
> Additional type syntax rule:
>
> type: ... | type generic-type| (type-list) generic-type
>
> or
>
> type: ... | type "-" generic-type | (type-list) "-" generic-type
>
> FWIW I thought of this four weeks ago (June 16).
>
> On Jul 14, 2020, at 3:29 PM, 'gri' via golang-nuts <
> golang-nuts@googlegroups.com> 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
>> 

Re: [go-nuts] Generics and parentheses

[Fino]

I vote for <: and :> 

type more on traditional keyboard is acceptable for me, since I don't use 
generics much.

too much parentheses ( and ) in declaration is really hard to read, 
confused my mind.

square brackets [ and ] should reserve for array and slice.

and, look ahead, we are able to just put <: and :>  on keyboard!

I have made several my own custom keyboard PCB and firmware. Report 2 scan 
code in one click is easy and simple!  Maximum 6 scancode send once per USB 
HID protocol. A lot of opensource firmware is there, for ex. 
https://github.com/qmk/qmk_firmware.  

On touch screen, layout of keyboard can change according to different 
context. This may happen to desktop keyboard too, with higher cost and more 
complex physical structure.  

BR fino



-- 
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/5bff3f80-8ac2-416c-89d3-e3ac8d284523o%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[Bakul Shah]

I don't much like square brackets or angle brackets or guillemets. But here is 
a different way
of reducing the need for parentheses at least for the common case:

A proposal for fewer irritating parentheses!

One thing to note is that generic functions & types are *different* from
existing things like const, func, type, var. As such they should have their
own declaration marker. For example

gen T   type pair struct { a, b T } // contrast with type pair(type 
T) ...
gen T,U type W struct { a T; b U }  // contrast with type W(type T, 
U) ...
gen T   func Print(s []T) {...} // print a slice of T

These function/type/method generics are used by *prepending* the type:

var x int pair  // a pair of ints
var y (int, int pair) W // here we have to use parentheses
int Print([]int{1,2,3}) // print a slice of ints
qq := int pair pair{{1,2},{3,4}} // a pair of a pair of ints
ww := (int, int) W pair{{1,2},{3,4}}

This use may seem weird if you are used to C/C++. I find it more readable
than having to deal with extra parentheses. "int pair" clearly says a
pair of ints and so on. What is more, if in future types are allowed to be
*inferred* for generic function calls, you can simply drop the type prefix.

If there is still a parsing ambiguity, I'd suggest adding a - as in int-pair.

Additional type syntax rule:

type: ... | type generic-type| (type-list) generic-type

or

type: ... | type "-" generic-type | (type-list) "-" generic-type

FWIW I thought of this four weeks ago (June 16).

> On Jul 14, 2020, at 3:29 PM, 'gri' via golang-nuts 
>  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 

Re: [go-nuts] Generics and parentheses

[Paul Johnston]

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

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

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

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

*type Vector []T*



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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e2459352-ab61-4bba-99a3-215496faaab5n%40googlegroups.com.

Re: [go-nuts] Generics and parentheses

[robert engels]

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/825D82DD-C595-415D-B0C6-7BE090A015C7%40ix.netcom.com.

Re: [go-nuts] Generics and parentheses

[David Riley]

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

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


- Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6C145CFD-7A43-4BAA-87AA-5E3AA00C068C%40gmail.com.

Re: [go-nuts] Generics and parentheses

[Harald Weidner]

Hello,

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

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

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

Regards,
Harald

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

[go-nuts] Generics and parentheses

['Robert Griesemer' via golang-nuts]

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

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

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

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

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

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

type A [N]E

cannot be distinguished from the generic type declaration

type A[N] E

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

type A[type N] E

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

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

using () using []

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

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

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

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

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

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

- gri, iant

PS: For ambiguities with angle brackets consider the assignment

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

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

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

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

(w)(z)

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

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