[go-nuts] Re: Generics

[ffm2002]

Here are some code generators that let you define template parameters:

https://github.com/cheekybits/genny
https://github.com/taylorchu/generic
https://github.com/joeshaw/gengen
https://github.com/clipperhouse/gen

Making use of Go templates:

https://github.com/ncw/gotemplate
https://github.com/droundy/gotgo

Am Dienstag, 11. Dezember 2018 04:00:57 UTC+1 schrieb Tharaneedharan 
Vilwanathan:
>
> Hi All,
>
> I have a quick question.
>
> What is the best choice for writing generic code till Go officially 
> supports generics? Just looking for some guidance.
>
> Regards
> dharani
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics

[Tharaneedharan Vilwanathan]

Thank you for the details!

Regards
dharani


On Tue, Dec 11, 2018 at 2:13 AM  wrote:

> Here are some code generators that let you define template parameters:
>
> https://github.com/cheekybits/genny
> https://github.com/taylorchu/generic
> https://github.com/joeshaw/gengen
> https://github.com/clipperhouse/gen
>
> Making use of Go templates:
>
> https://github.com/ncw/gotemplate
> https://github.com/droundy/gotgo
>
> Am Dienstag, 11. Dezember 2018 04:00:57 UTC+1 schrieb Tharaneedharan
> Vilwanathan:
>>
>> Hi All,
>>
>> I have a quick question.
>>
>> What is the best choice for writing generic code till Go officially
>> supports generics? Just looking for some guidance.
>>
>> Regards
>> dharani
>>
>> --
> You received this message because you are subscribed 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics

[michal]

Google has it's own tool that is publicly available as part of gvisor 
project [1] I think it's as good or better than the provided options.
I copied that to enable installation using plain go get (without bazel) [2].
We used that to de-interface github.com/fatih/set so you may see a real 
usage example [3].

[1] https://github.com/google/gvisor/tree/master/tools/go_generics
[2] https://github.com/mmatczuk/go_generics
[3] https://github.com/scylladb/go-set

$ go get github.com/mmatczuk/go_generics/cmd/...
$ go_generics -h
Usage: go_generics [options]
  -ast
prints the AST
  -c A=B
reassign constant A to value B when A=B is passed in. Multiple such 
mappings are allowed.
  -i file
input file
  -import name=path
specifies the import libraries to use when types are not local. 
name=path specifies that 'name', used in types as name.type, refers to the 
package living in 'path'.
  -o file
output file
  -p name
output package name (default "main")
  -prefix prefix
prefix to add to each global symbol
  -suffix suffix
suffix to add to each global symbol
  -t A=B
rename type A to B when A=B is passed in. Multiple such mappings 
are allowed.

On Tuesday, December 11, 2018 at 11:25:57 PM UTC+1, Tharaneedharan 
Vilwanathan wrote:
>
> Thank you for the details!
>
> Regards
> dharani
>
>
> On Tue, Dec 11, 2018 at 2:13 AM > wrote:
>
>> Here are some code generators that let you define template parameters:
>>
>> https://github.com/cheekybits/genny
>> https://github.com/taylorchu/generic
>> https://github.com/joeshaw/gengen
>> https://github.com/clipperhouse/gen
>>
>> Making use of Go templates:
>>
>> https://github.com/ncw/gotemplate
>> https://github.com/droundy/gotgo
>>
>> Am Dienstag, 11. Dezember 2018 04:00:57 UTC+1 schrieb Tharaneedharan 
>> Vilwanathan:
>>>
>>> Hi All,
>>>
>>> I have a quick question.
>>>
>>> What is the best choice for writing generic code till Go officially 
>>> supports generics? Just looking for some guidance.
>>>
>>> Regards
>>> dharani
>>>
>>> -- 
>> You received this message because you are subscribed 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 .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics

[Tharaneedharan Vilwanathan]

This is great! Thanks for the details, michal!

Regards
dharani

On Wed, Dec 12, 2018 at 12:27 AM  wrote:

> Google has it's own tool that is publicly available as part of gvisor
> project [1] I think it's as good or better than the provided options.
> I copied that to enable installation using plain go get (without bazel)
> [2].
> We used that to de-interface github.com/fatih/set so you may see a real
> usage example [3].
>
> [1] https://github.com/google/gvisor/tree/master/tools/go_generics
> [2] https://github.com/mmatczuk/go_generics
> [3] https://github.com/scylladb/go-set
>
> $ go get github.com/mmatczuk/go_generics/cmd/...
> $ go_generics -h
> Usage: go_generics [options]
>   -ast
> prints the AST
>   -c A=B
> reassign constant A to value B when A=B is passed in. Multiple
> such mappings are allowed.
>   -i file
> input file
>   -import name=path
> specifies the import libraries to use when types are not local.
> name=path specifies that 'name', used in types as name.type, refers to the
> package living in 'path'.
>   -o file
> output file
>   -p name
> output package name (default "main")
>   -prefix prefix
> prefix to add to each global symbol
>   -suffix suffix
> suffix to add to each global symbol
>   -t A=B
> rename type A to B when A=B is passed in. Multiple such mappings
> are allowed.
>
> On Tuesday, December 11, 2018 at 11:25:57 PM UTC+1, Tharaneedharan
> Vilwanathan wrote:
>>
>> Thank you for the details!
>>
>> Regards
>> dharani
>>
>>
>> On Tue, Dec 11, 2018 at 2:13 AM  wrote:
>>
>>> Here are some code generators that let you define template parameters:
>>>
>>> https://github.com/cheekybits/genny
>>> https://github.com/taylorchu/generic
>>> https://github.com/joeshaw/gengen
>>> https://github.com/clipperhouse/gen
>>>
>>> Making use of Go templates:
>>>
>>> https://github.com/ncw/gotemplate
>>> https://github.com/droundy/gotgo
>>>
>>> Am Dienstag, 11. Dezember 2018 04:00:57 UTC+1 schrieb Tharaneedharan
>>> Vilwanathan:

 Hi All,

 I have a quick question.

 What is the best choice for writing generic code till Go officially
 supports generics? Just looking for some guidance.

 Regards
 dharani

 --
>>> You received this message because you are subscribed 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.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics

[Tharaneedharan Vilwanathan]

BTW, I understand generics is not top priority and will show up in Go
sometime later. But I happened to notice data structure code with generics.
I liked the idea of writing code once for all data types. For example:

https://github.com/raywenderlich/swift-algorithm-club
https://github.com/raywenderlich/swift-algorithm-club/blob/master/Stack/Stack.swift

Hope someday we will have one like this for Go.

Regards
dharani

On Wed, Dec 12, 2018 at 12:37 AM Tharaneedharan Vilwanathan <
vdhar...@gmail.com> wrote:

> This is great! Thanks for the details, michal!
>
> Regards
> dharani
>
> On Wed, Dec 12, 2018 at 12:27 AM  wrote:
>
>> Google has it's own tool that is publicly available as part of gvisor
>> project [1] I think it's as good or better than the provided options.
>> I copied that to enable installation using plain go get (without bazel)
>> [2].
>> We used that to de-interface github.com/fatih/set so you may see a real
>> usage example [3].
>>
>> [1] https://github.com/google/gvisor/tree/master/tools/go_generics
>> [2] https://github.com/mmatczuk/go_generics
>> [3] https://github.com/scylladb/go-set
>>
>> $ go get github.com/mmatczuk/go_generics/cmd/...
>> $ go_generics -h
>> Usage: go_generics [options]
>>   -ast
>> prints the AST
>>   -c A=B
>> reassign constant A to value B when A=B is passed in. Multiple
>> such mappings are allowed.
>>   -i file
>> input file
>>   -import name=path
>> specifies the import libraries to use when types are not local.
>> name=path specifies that 'name', used in types as name.type, refers to the
>> package living in 'path'.
>>   -o file
>> output file
>>   -p name
>> output package name (default "main")
>>   -prefix prefix
>> prefix to add to each global symbol
>>   -suffix suffix
>> suffix to add to each global symbol
>>   -t A=B
>> rename type A to B when A=B is passed in. Multiple such mappings
>> are allowed.
>>
>> On Tuesday, December 11, 2018 at 11:25:57 PM UTC+1, Tharaneedharan
>> Vilwanathan wrote:
>>>
>>> Thank you for the details!
>>>
>>> Regards
>>> dharani
>>>
>>>
>>> On Tue, Dec 11, 2018 at 2:13 AM  wrote:
>>>
 Here are some code generators that let you define template parameters:

 https://github.com/cheekybits/genny
 https://github.com/taylorchu/generic
 https://github.com/joeshaw/gengen
 https://github.com/clipperhouse/gen

 Making use of Go templates:

 https://github.com/ncw/gotemplate
 https://github.com/droundy/gotgo

 Am Dienstag, 11. Dezember 2018 04:00:57 UTC+1 schrieb Tharaneedharan
 Vilwanathan:
>
> Hi All,
>
> I have a quick question.
>
> What is the best choice for writing generic code till Go officially
> supports generics? Just looking for some guidance.
>
> Regards
> dharani
>
> --
 You received this message because you are subscribed 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.
 For more options, visit https://groups.google.com/d/optout.

>>> --
>> You received this message because you are subscribed 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [generics] Closure?

[Bebop Leaf]

Like this:
https://go2goplay.golang.org/p/Veu_6glrHbn

It is tricky that you need to write `(_ Foo(T))` as the returning value 
declaration. Otherwise, the current parser consider it as calling the 
function with argument T and returns a value of type Foo, or in case of 
`(Foo(T))`, it is considered as `(Foo T)`, which is named return.

This is mentioned partly at 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#using-generic-types-as-unnamed-function-parameter-types.
 
But I think at lease it should be updated to include return value 
declaration.

-- 
You received this message because you are subscribed 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/e26bf937-74c3-4562-b1f4-a1ea34518943o%40googlegroups.com.

[go-nuts] Re: [generics] Closure?

['Bryan C. Mills' via golang-nuts]

I think this is a bug in the parser, related to (but not the same as) 
https://golang.org/design/go2draft-type-parameters#instantiating-types-in-type-literals
.

Adding doubled parentheses seems to make it work 
(https://go2goplay.golang.org/p/JSQ_8kGOC_A), but the `Format` button 
doesn't preserve them.

I would recommend filing an issue per 
https://go.googlesource.com/go/+/refs/heads/dev.go2go/README.go2go.md.
On Thursday, June 18, 2020 at 2:18:48 PM UTC-4 teiva...@gmail.com wrote:

> Hello,
>
> I didn't find in the latest draft design any mention of generics with 
> closure and I'm struggling in having something working:
>
> type Foo(type T) struct {}
>
> func bar(type T)() Foo(T) {
>return func() Foo(T) {
>   return Foo(T){}
>}()
> }
>
>
> In this example, how can I create a closure that would return a *Foo(T)*?
>
> Here is the playground: https://go2goplay.golang.org/p/N-b10vSCois
>
> Cheers
>

-- 
You received this message because you are subscribed 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/472dc188-3b01-40bb-a56c-8c22f2782cf3n%40googlegroups.com.

[go-nuts] Re: [generics] opposed

[Viktor Kojouharov]

"Doesn't really need to be there" is highly subjective

On Friday, August 28, 2020 at 7:10:45 PM UTC+2 Ashton Cummings wrote:

> My first impression of Go not having generics was negative. I came from 
> C#, Java, typescript, C++, and a few other languages that had generics. So, 
> learning Go and finding that it did not have it, was disappointing. 1 year 
> later and i am still using Go. However, my opinion has changed. I have 
> slowly adapted the Go mindset. Keep it simple. Go has this ability to just 
> keep things super simple. Easy to read and easy to implement. No overly 
> complicated designs, just simple code. I have really enjoyed working with 
> it. Adding generics to Go does not destroy that "keep it simple" mindset, 
> but i do believe it will add complexity to code that doesn't really need to 
> be there.
>
> I currently oppose it. However, i am open minded and can be convinced to 
> be happy about the change. Either way, i am still going to be using Go. =)
>
> -- 
>
> -Ashton Cummings
>

-- 
You received this message because you are subscribed 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/63faf96a-c714-492d-a542-5aaeb5b177e0n%40googlegroups.com.

[go-nuts] Re: Generics are overrated.

[prades . marq]

What is overrated is the use of "interface { }" and reflection AKA runtime 
magics which has no place in a modern statically typed language. It's a 
cop-out, it's dirty and a direct consequence of the absence of generics in 
Go.

> Please provide some best practices to achieve generic behavior for the 
most common cases, instead of implementing Generics in Go.

You cannot achieve generic behavior without some form of generics. Look at 
sync.Map it's not compile time type safe. With generics it would be. 



Le vendredi 28 juillet 2017 14:41:10 UTC+2, dogan...@dodobyte.com a écrit :
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely different programming 
> styles.
>
> Dear Go experts;
>
> Please provide some best practices to achieve generic behavior for the 
> most common cases, instead of implementing Generics in Go.
>
> Let's end this debate and help keeping Go small and simple. It's the real 
> virtue of Go. 
>
> Thanks.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Roberto Zanotto]

I love playing with package reflect, which is much more powerful than 
generics by the way (you can't implement gob or json with generics).

On Saturday, July 29, 2017 at 3:28:56 PM UTC+2, M P r a d e s wrote:
>
> What is overrated is the use of "interface { }" and reflection AKA runtime 
> magics which has no place in a modern statically typed language. It's a 
> cop-out, it's dirty and a direct consequence of the absence of generics in 
> Go.
>
> > Please provide some best practices to achieve generic behavior for the 
> most common cases, instead of implementing Generics in Go.
>
> You cannot achieve generic behavior without some form of generics. Look at 
> sync.Map it's not compile time type safe. With generics it would be. 
>
>
>
> Le vendredi 28 juillet 2017 14:41:10 UTC+2, dogan...@dodobyte.com a 
> écrit :
>>
>> *Everything in this thread is my personal opinions, they are not 
>> necessarily the truth.*
>>
>> My main language was C for a decade. I also liked Python. When i started 
>> learning Go, it almost felt like i knew the language in another life. 
>> Everything was so obvious.
>>
>> CSP model of concurrency was new to me though. Interfaces were more 
>> familiar due to unix's open,close,read,write interface, which is the 
>> greatest idea.
>>
>> I didn't use generics or templates much (it's kind of stupid for me to 
>> talk about it's necessity), therefore this is more like a meta-research.
>>
>> - Go developers created a great standard library and many great software 
>> without generics in the language.
>> - Many companies switched to Go from the languages that have generics in 
>> it.
>> - A little copying is better than having a big feature in the language.
>> - Using generics everywhere is more of a design choice than a necessity.
>>
>>
>> *A language that doesn’t have everything is actually easier to program in 
>> than some that do. (Dennis Ritchie).*
>>
>> I wrote many different types of software in C. A country wide (a big one) 
>> server, two AV engines for two major AV companies etc. I needed generics 
>> only few times, but i could handle it in C without using smart tricks. In 
>> Go however, there are much safer, better and elegant solutions to achieve 
>> the same results. Do we really need a big feature for it?
>>
>> I didn't hear a complaint about the lack of generics in Go from a C 
>> programmer, although i'm sure there are. 
>> Maybe java programmers use generics more than they are supposed to. Maybe 
>> they should stop writing java in Go. I am confident that they would abuse 
>> generics if Go had one.
>>
>> That brings me to my point.
>>
>> I believe that generics would divide the Go community.
>>
>> It's well known that everybody uses a subset of C++ language. Google 
>> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
>> C++ in my last company and i felt the pain.
>>
>> Rob Pike himself talked about it. 
>> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>>
>> Now Go is unique because people come to Go from all kind of different 
>> languages, (javascript, Python, C,...). see 
>> https://blog.golang.org/survey2016-results
>>
>> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
>> will look alien to Go 1 programmers. Some people will not use generics at 
>> all while others overuse it.
>>
>> For a language like Go, this is disastrous because it's against Go's 
>> philosophy. I love gofmt because it enforces a standart format and saves 
>> our time of debating about indention and other things. What good it is to 
>> have a standard format while you have completely different programming 
>> styles.
>>
>> Dear Go experts;
>>
>> Please provide some best practices to achieve generic behavior for the 
>> most common cases, instead of implementing Generics in Go.
>>
>> Let's end this debate and help keeping Go small and simple. It's the real 
>> virtue of Go. 
>>
>> Thanks.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[prades . marq]

I love playing with package reflect, which is much more powerful than 
generics by the way (you can't implement gob or json with generics).

You could absolutely do that without runtime reflection. It is called 
compile time type safe macros ... Oh wait, Rust has them, and generics and 
a correct implementation of method polymorphism... 

Le samedi 29 juillet 2017 15:44:26 UTC+2, Roberto Zanotto a écrit :
>
> I love playing with package reflect, which is much more powerful than 
> generics by the way (you can't implement gob or json with generics).
>
> On Saturday, July 29, 2017 at 3:28:56 PM UTC+2, M P r a d e s wrote:
>>
>> What is overrated is the use of "interface { }" and reflection AKA 
>> runtime magics which has no place in a modern statically typed language. 
>> It's a cop-out, it's dirty and a direct consequence of the absence of 
>> generics in Go.
>>
>> > Please provide some best practices to achieve generic behavior for the 
>> most common cases, instead of implementing Generics in Go.
>>
>> You cannot achieve generic behavior without some form of generics. Look 
>> at sync.Map it's not compile time type safe. With generics it would be. 
>>
>>
>>
>> Le vendredi 28 juillet 2017 14:41:10 UTC+2, dogan...@dodobyte.com a 
>> écrit :
>>>
>>> *Everything in this thread is my personal opinions, they are not 
>>> necessarily the truth.*
>>>
>>> My main language was C for a decade. I also liked Python. When i started 
>>> learning Go, it almost felt like i knew the language in another life. 
>>> Everything was so obvious.
>>>
>>> CSP model of concurrency was new to me though. Interfaces were more 
>>> familiar due to unix's open,close,read,write interface, which is the 
>>> greatest idea.
>>>
>>> I didn't use generics or templates much (it's kind of stupid for me to 
>>> talk about it's necessity), therefore this is more like a meta-research.
>>>
>>> - Go developers created a great standard library and many great software 
>>> without generics in the language.
>>> - Many companies switched to Go from the languages that have generics in 
>>> it.
>>> - A little copying is better than having a big feature in the language.
>>> - Using generics everywhere is more of a design choice than a necessity.
>>>
>>>
>>> *A language that doesn’t have everything is actually easier to program 
>>> in than some that do. (Dennis Ritchie).*
>>>
>>> I wrote many different types of software in C. A country wide (a big 
>>> one) server, two AV engines for two major AV companies etc. I needed 
>>> generics only few times, but i could handle it in C without using smart 
>>> tricks. In Go however, there are much safer, better and elegant solutions 
>>> to achieve the same results. Do we really need a big feature for it?
>>>
>>> I didn't hear a complaint about the lack of generics in Go from a C 
>>> programmer, although i'm sure there are. 
>>> Maybe java programmers use generics more than they are supposed to. 
>>> Maybe they should stop writing java in Go. I am confident that they would 
>>> abuse generics if Go had one.
>>>
>>> That brings me to my point.
>>>
>>> I believe that generics would divide the Go community.
>>>
>>> It's well known that everybody uses a subset of C++ language. Google 
>>> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
>>> C++ in my last company and i felt the pain.
>>>
>>> Rob Pike himself talked about it. 
>>> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>>>
>>> Now Go is unique because people come to Go from all kind of different 
>>> languages, (javascript, Python, C,...). see 
>>> https://blog.golang.org/survey2016-results
>>>
>>> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
>>> will look alien to Go 1 programmers. Some people will not use generics at 
>>> all while others overuse it.
>>>
>>> For a language like Go, this is disastrous because it's against Go's 
>>> philosophy. I love gofmt because it enforces a standart format and saves 
>>> our time of debating about indention and other things. What good it is to 
>>> have a standard format while you have completely different programming 
>>> styles.
>>>
>>> Dear Go experts;
>>>
>>> Please provide some best practices to achieve generic behavior for the 
>>> most common cases, instead of implementing Generics in Go.
>>>
>>> Let's end this debate and help keeping Go small and simple. It's the 
>>> real virtue of Go. 
>>>
>>> Thanks.
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[dogan . kurt]

I was watching rus cox's last talk 
 and he mentioned that not 
every problem should be solved by language change. Some can be solved by 
tooling or library change. 

I am curious has any of the generics lovers written a tool that helps for 
generic behavior. Something like,*

//@generic
func Max(x, y T) T {
if x > y {
return x
}
return y
}

When the tool sees generic comment, it rewrites the function for each type 
as called, like Maxi(x, y int) int, Maxf64(x, y float64) float64 etc..

** I know there are many issues with this example but it's just to show my 
point*

I know people wrote tools like goimports, gocode out of real needs, and 
they are everywhere. 
I just want to know sincerely, if people REALLY need generics so much, or 
they are just complaining because they are used to it and it's in their 
favorite programming language.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[mhhcbon]

i have not read this,

1. i do go because the type system is helping me,
if i do js, i have no type system, so i have to figure this out by myself, 
its hard
if i d be doing java, i d end up with complex giant scaled type hierarchy, 

both cases, it d more a difficulty than an helper to my attempt to solve a 
real problem.

2. generics / not generics ?
i d rather think in terms of *capability*.
- i can t declare a func which returns the type it received, i feel like 
its a lack of basic capability.
- i can t generalize easily / elegantly some algo, again this looks likes a 
basic functionality.

should any of this be necessarily over complex, *i hope not*.

should any existing implementation is the right one, i believe not, for as 
much as i know (not that much, true :),
because they thought generics as a piece of software to integrate in a 
complex hierarchy of types (so they needed to parametrized their generics),
they made generics in their ways of thinking.

The day GO has found its way around those two difficulties *using **its way 
of thinking*,
- how to let the runtime leaks into the static type system (dont pre 
emptively define the world, locally solves problems)
- elegantly provide re usable algo (be DRY)
it d be an awesome language to write.

As a comparison, quickly i want to talk about php, before php4, there was 
not a type system,
since php5 they implemented a type system with class hierarchy based on 
Java and co (so called "leaders"),
IMHO, a total failure, php is no more php, its not java and co either, it 
became a bloat,
years later, i think about it and wish they took their inspiration from the 
go language,
they did not.

Do i want GO to become java because "its a leader", really not please, i d 
rather keep go 1.

3. compile time worries
I found it inadequate to worries yet about the compiler speed without a 
clear and meaningful change proposal.
Also, i wonder if we are worrying about a compilation time with no-cache, 
or with a hot cache.
Said as a question, is it a worry about 1% use case, or the 99% use cases ?
The consequence would be, how to re think this worry with new metrics, 
thresholds, explanations ?


On Friday, July 28, 2017 at 2:41:10 PM UTC+2, dogan...@dodobyte.com wrote:
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely d

[go-nuts] Re: Generics are overrated.

[dogan . kurt]

Daily reminder: This thread was about concerns that generics would divide 
Go community. Not about necessity of generics in general.

Two possible scenarios:

1) Go have programmers from very different backgrounds, some used generics 
often while others never used it. (e.g. Java and C). So different people 
will use different features of Go with different style and practices. This 
is the C++ mistake.

2) Go 2 will have such a fundamental new feature and Go 1 programmers will 
avoid Go 2. To use old code base with Go 2, you have two options;
 a- Mix Go 1 code with Go 2 code, new code uses generics while old code 
does not.
 b- Update Go 1 code to utilize generics.

Personally i would rather stay with Go 1. This is the Python mistake.

I may be wrong, this is only my concerns. 

Thanks.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[mhhcbon]

"This thread was about concerns that generics would divide Go community"

that d would dismiss any attempt to propose generics *because* it s 
generics,
instead of the observation that the proposal does breaks everything 
including the community.

maybe the first thing to do is to ban this word "generics", so we can start 
thinking about facts,
rather than trying to pull a model and put it into go ?


On Sunday, July 30, 2017 at 3:14:27 PM UTC+2, dogan...@dodobyte.com wrote:
>
> Daily reminder: This thread was about concerns that generics would divide 
> Go community. Not about necessity of generics in general.
>
> Two possible scenarios:
>
> 1) Go have programmers from very different backgrounds, some used generics 
> often while others never used it. (e.g. Java and C). So different people 
> will use different features of Go with different style and practices. This 
> is the C++ mistake.
>
> 2) Go 2 will have such a fundamental new feature and Go 1 programmers will 
> avoid Go 2. To use old code base with Go 2, you have two options;
>  a- Mix Go 1 code with Go 2 code, new code uses generics while old code 
> does not.
>  b- Update Go 1 code to utilize generics.
>
> Personally i would rather stay with Go 1. This is the Python mistake.
>
> I may be wrong, this is only my concerns. 
>
> Thanks.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Mandolyte]

Just a reminder that Egon Elbre's documentation of all the discussions on 
this topic is here:

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4


-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[David Collier-Brown]

I came to Go from languages that had generics, but in practice I find that 
I predominantly used list-of and  set-of.  And I spent a dispropriate 
amount of time with valgrind making sure my C++ list didn't have leaks (:-()

A question to people who use Java/C++ and friends: what generics do you 
find you use in *production* programs?

--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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Mandolyte]

It's been many years since I was involved in developing complex systems 
(C++ and Java). But I agree, it was mostly lists and sets with searching 
and sorting. But I also used them for algorithms a good bit. Thus I would 
guess that the maintainers of GONUM libraries might benefit (anyone 
confirm?).

I haven't seen many libraries developed in Go yet, but I think it likely 
many would benefit from generics. And I think it could simple and readable. 
I tend to think of it as an analogue to `go generate`. The latter is for 
package *authors*... a similar feature for package *users *is all that is 
needed.

On Sunday, July 30, 2017 at 5:08:46 PM UTC-4, David Collier-Brown wrote:
>
> I came to Go from languages that had generics, but in practice I find that 
> I predominantly used list-of and  set-of.  And I spent a dispropriate 
> amount of time with valgrind making sure my C++ list didn't have leaks (:-()
>
> A question to people who use Java/C++ and friends: what generics do you 
> find you use in *production* programs?
>
> --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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Tristan Colgate]

On Mon, 31 Jul 2017, 18:21 roger peppe,  wrote:

>
> > import hpaInformer informer
> >
> > myInformer := hpaInformer.New(sharedUnderlyingCacheThing)
>
> So... to me, the implementation of NewHorizontalPodAutoscalerInformer looks
> pretty much exactly like what you've got there, where
> sharedUnderlyingCacheThing
> is the result of cache.NewSharedIndexInformer as called currently in the
> code. That is, that constructor inside the call to NewSharedIndexInformer
> seems a lot like a constructor for sharedUnderlyingCacheThing to me.
> I'm not entirely convinced that generics would make the code much
> cleaner in this case.
>

The duplication I'm thinking about is more the multiple packages, one for
each type being informed on. If the top level informers package, or
function, were templatable by the type being informed on, there would be no
need for the per-type packages. As it stands there is little benefit from
the godocs for each individual informer. The current docs are verbose well
beyond the value they add.


>
> You might want to experiment by refactoring some of that k8s code to use
> generics (using whatever your preferred formulation might be) and see
> what it might look like, and whether it looks significantly
> nicer/simpler/cleaner
> as a result
>

I might look at something for the informers case, but it's worth pointing
out that I was thinking generics could provide a difference API, rather
than a cleaner implementation of the existing one.


> I suspect that it might not look that much different - whether you're using
> type-parametric polymorphism or interfaces, somehow you've got to
> plug the specific code into the generic code, and that existing k8s code
> doesn't look like it has that much redundant boilerplate to it.
>
>   cheers,
> rog.
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Dorival Pedroso]

Agreed!

And I was a "heavy" user of templates (see e.g. http://mechsys.nongnu.org/, 
including extensive use of "expression templates") ~5 years ago before the 
"wonders of Go".

Let's focus on making Go faster instead!

Cheers.
Dorival

On Friday, July 28, 2017 at 10:41:10 PM UTC+10, dogan...@dodobyte.com wrote:
>
> *Everything in this thread is my personal opinions, they are not 
> necessarily the truth.*
>
> My main language was C for a decade. I also liked Python. When i started 
> learning Go, it almost felt like i knew the language in another life. 
> Everything was so obvious.
>
> CSP model of concurrency was new to me though. Interfaces were more 
> familiar due to unix's open,close,read,write interface, which is the 
> greatest idea.
>
> I didn't use generics or templates much (it's kind of stupid for me to 
> talk about it's necessity), therefore this is more like a meta-research.
>
> - Go developers created a great standard library and many great software 
> without generics in the language.
> - Many companies switched to Go from the languages that have generics in 
> it.
> - A little copying is better than having a big feature in the language.
> - Using generics everywhere is more of a design choice than a necessity.
>
>
> *A language that doesn’t have everything is actually easier to program in 
> than some that do. (Dennis Ritchie).*
>
> I wrote many different types of software in C. A country wide (a big one) 
> server, two AV engines for two major AV companies etc. I needed generics 
> only few times, but i could handle it in C without using smart tricks. In 
> Go however, there are much safer, better and elegant solutions to achieve 
> the same results. Do we really need a big feature for it?
>
> I didn't hear a complaint about the lack of generics in Go from a C 
> programmer, although i'm sure there are. 
> Maybe java programmers use generics more than they are supposed to. Maybe 
> they should stop writing java in Go. I am confident that they would abuse 
> generics if Go had one.
>
> That brings me to my point.
>
> I believe that generics would divide the Go community.
>
> It's well known that everybody uses a subset of C++ language. Google 
> doesn't use exceptions for instance(afaik). I was unfortunate enough to use 
> C++ in my last company and i felt the pain.
>
> Rob Pike himself talked about it. 
> https://talks.golang.org/2012/splash.article (see 4. Pain points)
>
> Now Go is unique because people come to Go from all kind of different 
> languages, (javascript, Python, C,...). see 
> https://blog.golang.org/survey2016-results
>
> If Go 2 has a new fundamental feature like generics, many Go 2 programs 
> will look alien to Go 1 programmers. Some people will not use generics at 
> all while others overuse it.
>
> For a language like Go, this is disastrous because it's against Go's 
> philosophy. I love gofmt because it enforces a standart format and saves 
> our time of debating about indention and other things. What good it is to 
> have a standard format while you have completely different programming 
> styles.
>
> Dear Go experts;
>
> Please provide some best practices to achieve generic behavior for the 
> most common cases, instead of implementing Generics in Go.
>
> Let's end this debate and help keeping Go small and simple. It's the real 
> virtue of Go. 
>
> Thanks.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[as . utf8]

I'm hesitant to accept generics due to the fear of *overloaded operators *being 
the next big deal*. *C# even has *properties (user-defined methods 
dispatched upon an assignment operation)*. 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Lucio]

(Some unjustifiable opinionated ramblings from a faraway place, read at 
your peril.)

It took Dijkstra quite some effort to accept the concept of "interrupts" 
(quotation anyone?), but eventually he went with it.

Resistance to operator overloading is as admirable as it is futile. 
Ultimately, the range of base types in a programming language is an 
arbitrary decision and the operators applied to them is equally an 
artifact, not divine inspiration. Go slipped badly when it added "+" as the 
string concatenation operator and I don't remember much resistance to that.

In fact, I have adopted the expression x += 1 in lieu of x++ in all my 
coding specifically because I don't think the increment operator is 
necessary at all; a circular shift operator has more merit, but no one asks 
for that. Nor has anyone, including Rob Pike, suggested that we head the 
APL route and add any available special symbols as operators. I can see 
why, of course!

I would expect programming languages one or two generations from now to 
resemble nature more closely and allow programs to evolve rather than be 
"written" or coded. For that, the basic building blocks have to change 
dramatically. But our guidance may well come from the DNA double helix and 
its very small range of components.

I find generics inelegant, they lack any aesthetic appeal and that was 
enough for templates to turn me off C++ 2.0, I hope that Go will not adopt 
similar ugliness. That said, if one could treat types as mutable properties 
of the language objects (variables that can be transformed between 
"compatible" types - a lot like interfaces allow presently, but much more 
visibly, perhaps, I haven't thought that hard about it), then "generic 
functions" would span such "types" intrinsically and still protect the 
program from mistakes at compile time. Hmm, if the type assertion was 
intrinsic rather than explicit, perhaps? We're trying to avoid that, so we 
need a concept as fresh as "type interface", but more amenable to 
enumeration, an explicit "type set" perhaps? I seem to remember something 
like that from "kencc"?

Ultimately, to return to the topic of operator overloading, with C++ they 
came before templates and templates were the inevitable progression. 
Interfaces are a different starting point and there is no immediately 
obvious progression from there, but maybe the Go "leading minds" haven't 
been looking. Maybe all we lack is the type of theory that went into 
describing SQL as a mathematical concept, applied to interfaces, just 
maybe...

A final thought: the Go.1 promise is a wonderful idea, since it encouraged 
a whole cultural group to look for every conceivable improvement that could 
be made to a very stable core. But of course it had to apply blinkers. 
Eventually, someone will peek over the edge of such blinkers and figure 
what we've all been missing. It is not a critical component, but once it or 
they are identified, it will be hard to imagine how they could have been 
missed for so long.

Lucio.

On Saturday, 5 August 2017 03:52:28 UTC+2, as@gmail.com wrote:
>
> I'm hesitant to accept generics due to the fear of *overloaded operators 
> *being 
> the next big deal*. *C# even has *properties (user-defined methods 
> dispatched upon an assignment operation)*. 
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[David Collier-Brown]

Ah well, one can always go back to

COPY PAYLIB REPLACING A BY PAYROLL
  B BY PAY-CODE
  C BY GROSS-PAY
  D BY HOURS.


(Courtesy of 
https://www.ibm.com/support/knowledgecenter/en/SSQ2R2_9.1.1/com.ibm.etools.cbl.win.doc/topics/rlcdscop.htm)

--dave (:-)) c-b

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[peterGo]

Lucio,

"It took Dijkstra quite some effort to accept the concept of "interrupts" 
(quotation anyone?), but eventually he went with it."

E.W. Dijkstra Archive: My recollections of operating system design (EWD1303)

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303.html

"The third arrangement, known as "the interrupt", circumvents all these 
dilemmas. While the computer calculates at full speed, a piece of dedicated 
hardware monitors the outside world for completion signals from 
communication devices. When a completion is detected, the program under 
execution is interrupted after the current instruction and in such a 
fashion that it can be resumed at a later moment as if nothing had 
happened, thus instantaneously freeing the central processor for a suddenly 
more urgent task. After the interrupt the processor would execute a 
standard program establishing the source of the interruption and taking 
appropriate action."

Peter

On Saturday, August 5, 2017 at 12:26:58 AM UTC-4, Lucio wrote:
>
> (Some unjustifiable opinionated ramblings from a faraway place, read at 
> your peril.)
>
> It took Dijkstra quite some effort to accept the concept of "interrupts" 
> (quotation anyone?), but eventually he went with it.
>
> Resistance to operator overloading is as admirable as it is futile. 
> Ultimately, the range of base types in a programming language is an 
> arbitrary decision and the operators applied to them is equally an 
> artifact, not divine inspiration. Go slipped badly when it added "+" as the 
> string concatenation operator and I don't remember much resistance to that.
>
> In fact, I have adopted the expression x += 1 in lieu of x++ in all my 
> coding specifically because I don't think the increment operator is 
> necessary at all; a circular shift operator has more merit, but no one asks 
> for that. Nor has anyone, including Rob Pike, suggested that we head the 
> APL route and add any available special symbols as operators. I can see 
> why, of course!
>
> I would expect programming languages one or two generations from now to 
> resemble nature more closely and allow programs to evolve rather than be 
> "written" or coded. For that, the basic building blocks have to change 
> dramatically. But our guidance may well come from the DNA double helix and 
> its very small range of components.
>
> I find generics inelegant, they lack any aesthetic appeal and that was 
> enough for templates to turn me off C++ 2.0, I hope that Go will not adopt 
> similar ugliness. That said, if one could treat types as mutable properties 
> of the language objects (variables that can be transformed between 
> "compatible" types - a lot like interfaces allow presently, but much more 
> visibly, perhaps, I haven't thought that hard about it), then "generic 
> functions" would span such "types" intrinsically and still protect the 
> program from mistakes at compile time. Hmm, if the type assertion was 
> intrinsic rather than explicit, perhaps? We're trying to avoid that, so we 
> need a concept as fresh as "type interface", but more amenable to 
> enumeration, an explicit "type set" perhaps? I seem to remember something 
> like that from "kencc"?
>
> Ultimately, to return to the topic of operator overloading, with C++ they 
> came before templates and templates were the inevitable progression. 
> Interfaces are a different starting point and there is no immediately 
> obvious progression from there, but maybe the Go "leading minds" haven't 
> been looking. Maybe all we lack is the type of theory that went into 
> describing SQL as a mathematical concept, applied to interfaces, just 
> maybe...
>
> A final thought: the Go.1 promise is a wonderful idea, since it encouraged 
> a whole cultural group to look for every conceivable improvement that could 
> be made to a very stable core. But of course it had to apply blinkers. 
> Eventually, someone will peek over the edge of such blinkers and figure 
> what we've all been missing. It is not a critical component, but once it or 
> they are identified, it will be hard to imagine how they could have been 
> missed for so long.
>
> Lucio.
>
> On Saturday, 5 August 2017 03:52:28 UTC+2, as@gmail.com wrote:
>>
>> I'm hesitant to accept generics due to the fear of *overloaded operators 
>> *being the next big deal*. *C# even has *properties (user-defined 
>> methods dispatched upon an assignment operation)*. 
>>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Lucio]

Thank you, Peter.

Maybe someone else can corroborate my impression that Dijkstra did not 
immediately accept the idea of interrupts and felt it would make 
programming too difficult?

Lucio.

On Saturday, 5 August 2017 19:44:26 UTC+2, peterGo wrote:
>
> Lucio,
>
> "It took Dijkstra quite some effort to accept the concept of "interrupts" 
> (quotation anyone?), but eventually he went with it."
>
> E.W. Dijkstra Archive: My recollections of operating system design 
> (EWD1303)
>
> https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1303.html
>
> "The third arrangement, known as "the interrupt", circumvents all these 
> dilemmas. While the computer calculates at full speed, a piece of dedicated 
> hardware monitors the outside world for completion signals from 
> communication devices. When a completion is detected, the program under 
> execution is interrupted after the current instruction and in such a 
> fashion that it can be resumed at a later moment as if nothing had 
> happened, thus instantaneously freeing the central processor for a suddenly 
> more urgent task. After the interrupt the processor would execute a 
> standard program establishing the source of the interruption and taking 
> appropriate action."
>
> Peter
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Lucio]

Got it. In the same document:

"Halfway the functional design of the X1, I guess early 1957, Bram and 
Carel confronted me with the idea of the interrupt, and I remember that I 
panicked, being used to machines with reproducible behaviour. How was I 
going to identify a bug if I had introduced one? After I had delayed the 
decision to include the interrupt for 3 months, Bram and Carel flattered me 
out of my resistance, it was decided that an interrupt would be included 
and I began to study the problem. To start with I tried to convince myself 
that it was possible to save and restore enough of the machine state so 
that, after the servicing of the interrupt, under all circumstances the 
interrupted computation could be resumed correctly."

Thank you again, Peter.

Lucio.


On Sunday, 6 August 2017 12:03:07 UTC+2, Lucio wrote:
>
> Thank you, Peter.
>
> Maybe someone else can corroborate my impression that Dijkstra did not 
> immediately accept the idea of interrupts and felt it would make 
> programming too difficult?
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Haddock]

In my opinion generics added to Go would make Go really take off. Currently 
Java developers would not change to Go. With Go having generics this would 
change and more people would consider Go also when not coming from 
Java/C#/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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[DV]

On Tuesday, August 8, 2017 at 5:37:42 AM UTC-6, Haddock wrote:
>
> In my opinion generics added to Go would make Go really take off. 
> Currently Java developers would not change to Go. With Go having generics 
> this would change and more people would consider Go also when not coming 
> from Java/C#/etc.
>

There's no way that any serious Java dev would ever consider Go, generics 
or not. Why, in Go, you justwrite code! In functions! Not a single 
AbstractSingletonFactoryImpl in sight! 

I used to do C# for a living, and Java before that. What drew me to Go was 
that it was *not* C# nor Java. That's actually the beautiful thing about 
it. 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[Haddock]

Am Mittwoch, 9. August 2017 23:29:13 UTC+2 schrieb DV:
>
>
>
> On Tuesday, August 8, 2017 at 5:37:42 AM UTC-6, Haddock wrote:
>>
>> In my opinion generics added to Go would make Go really take off. 
>> Currently Java developers would not change to Go. With Go having generics 
>> this would change and more people would consider Go also when not coming 
>> from Java/C#/etc.
>>
>
> There's no way that any serious Java dev would ever consider Go, generics 
> or not. Why, in Go, you justwrite code! In functions! Not a single 
> AbstractSingletonFactoryImpl in sight! 
>
> I used to do C# for a living, and Java before that. What drew me to Go was 
> that it was *not* C# nor Java. That's actually the beautiful thing about 
> it. 
>

Go does not have the modeling power of Java, C#, Python, etc. The language 
is too simple for that. So Go is not really the real thing for application 
development. But generics would make it possible to drag many things up. 

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[gary . willoughby]

Using D syntax:

func (r MyType) foo(A, B)(x A, y B) (z B, err error) {
...
}

result, _ := MyType.foo!(int, int)(10, 20)

Also, there's no reason why A and B can't be inferred:

result, _ := MyType.foo(10, 20)

It looks alright to me and very useful!


On Thursday, 24 August 2017 16:14:58 UTC+1, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[mhhcbon]

Why would you put generics on a method ?

The syntax you demonstrate is horrible, indeed.

what if generics are type related

type notFinal struct {
   p1 
   p2 
}

func (n notFinal) whatever(in ) string {
   return fmt.Sprintf(in) // anything to interface{}, works.
}

type Final notFinal

Final.whatever(1) // "1"

//notFinal not instantiable, not type assertable



Or func related

type notFinal func(in ) string

func Final notFinal

Final(1) // "1"


That said, ultimately, the more the syntax is parametrized the more complex 
it become. when there are many func signature as you demonstrate, it will 
get worse.

Named type might help, could be vetted too ?

Also 
none of this is as powerful as code gen.
None of those examples are better than interface{}.

On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[Viktor Kojouharov]

func Foo(in interface{}) {
val, ok := in.(someTypeOrInterface)
if !ok {
 // TODO HANDLE ERROR
}
   ...
}


Wow, this is so much more readable /s


On Thursday, August 24, 2017 at 6:14:58 PM UTC+3, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[Egon]

package tree

type Node<$Entry> struct {
Value $Entry
Left  *Node<$Entry>
Right *Node<$Entry>
}

func (node *Node) Insert(value node.$Entry) {
var side **Node
if node.Value.Less(value) {
side = &node.Right
} else {
side = &node.Left
} 

if *side == nil {
*side = &Node{Value: value}
} else {
(*side).Insert(value)
}
}

--

package tree

type Entry generic {
Less(Entry) bool
}

type Node struct {
Value Entry
Left  *Node
Right *Node
}

func (node *Node) Insert(value Entry) {
var side *Node
if node.Value.Less(value) {
side = &node.Right
} else {
side = &node.Left
} 

if *side == nil {
*side = &Node{Value: value}
} else {
(*side).Insert(value)
}
}


On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>
> Why would you put generics on a method ?
>
> The syntax you demonstrate is horrible, indeed.
>
> what if generics are type related
>
> type notFinal struct {
>p1 
>p2 
> }
>
> func (n notFinal) whatever(in ) string {
>return fmt.Sprintf(in) // anything to interface{}, works.
> }
>
> type Final notFinal
>
> Final.whatever(1) // "1"
>
> //notFinal not instantiable, not type assertable
>
>
>
> Or func related
>
> type notFinal func(in ) string
>
> func Final notFinal
>
> Final(1) // "1"
>
>
> That said, ultimately, the more the syntax is parametrized the more 
> complex it become. when there are many func signature as you demonstrate, 
> it will get worse.
>
> Named type might help, could be vetted too ?
>
> Also 
> none of this is as powerful as code gen.
> None of those examples are better than interface{}.
>
> On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>>
>> A lot of people like Go because code is very readable even for beginners.
>>
>> func f(x, y int)
>>
>> f is a function that receives x and y as int parameters, returning 
>> nothing. Simple enough.
>>
>> func f(x, y int) int
>>
>> f is a function that receives x and y as int parameters, returning yet 
>> another int. Fine.
>>
>> func f(x, y int) (z int, err error)
>>
>> f is a function that receives x and y as int parameters, returning two 
>> values: a first int, that we name z and an error named err. A little bit 
>> weird, but ok.
>>
>> func (r MyType) f(x, y int) (z int, err error)
>>
>> f is a method for a value of type MyType, henceforth named r, that 
>> receives x and y as int parameters, returning two values: a first int, that 
>> we name z and an error named err. Definitely not so simple.
>>
>>  func (r genType1) f(x, y genType2) (z getType2, err 
>> error)
>>
>> You must be kidding. STOP RIGHT THERE!
>>
>>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[mhhcbon]

In first example Value can not do Less, its Entry, Entry has not been 
defined yet, its nothing.
Unless you introduce a Lesser interface and specify Node<$Entry:Lesser>

Given that specific example this notation looks pretty heavy, 
and even worse if d that be 
As this is all scoped into a type definition, why this prefix "node." ?
Also there s node everywhere, its confusing.


I m confused by the second example, the package declaration seems to 
declare what should be parametric.
It looks weird to import from another package.
Entry generic type is an interface, isn it ?


apart from this, why is side a double pointer ?


On Friday, August 25, 2017 at 10:11:11 AM UTC+2, Egon wrote:
>
> package tree
>
> type Node<$Entry> struct {
> Value $Entry
> Left  *Node<$Entry>
> Right *Node<$Entry>
> }
>
> func (node *Node) Insert(value node.$Entry) {
> var side **Node
> if node.Value.Less(value) {
> side = &node.Right
> } else {
> side = &node.Left
> } 
>
> if *side == nil {
> *side = &Node{Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
> --
>
> package tree
>
> type Entry generic {
> Less(Entry) bool
> }
>
> type Node struct {
> Value Entry
> Left  *Node
> Right *Node
> }
>
> func (node *Node) Insert(value Entry) {
> var side *Node
> if node.Value.Less(value) {
> side = &node.Right
> } else {
> side = &node.Left
> } 
>
> if *side == nil {
> *side = &Node{Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
>
> On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>>
>> Why would you put generics on a method ?
>>
>> The syntax you demonstrate is horrible, indeed.
>>
>> what if generics are type related
>>
>> type notFinal struct {
>>p1 
>>p2 
>> }
>>
>> func (n notFinal) whatever(in ) string {
>>return fmt.Sprintf(in) // anything to interface{}, works.
>> }
>>
>> type Final notFinal
>>
>> Final.whatever(1) // "1"
>>
>> //notFinal not instantiable, not type assertable
>>
>>
>>
>> Or func related
>>
>> type notFinal func(in ) string
>>
>> func Final notFinal
>>
>> Final(1) // "1"
>>
>>
>> That said, ultimately, the more the syntax is parametrized the more 
>> complex it become. when there are many func signature as you demonstrate, 
>> it will get worse.
>>
>> Named type might help, could be vetted too ?
>>
>> Also 
>> none of this is as powerful as code gen.
>> None of those examples are better than interface{}.
>>
>> On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>>>
>>> A lot of people like Go because code is very readable even for beginners.
>>>
>>> func f(x, y int)
>>>
>>> f is a function that receives x and y as int parameters, returning 
>>> nothing. Simple enough.
>>>
>>> func f(x, y int) int
>>>
>>> f is a function that receives x and y as int parameters, returning yet 
>>> another int. Fine.
>>>
>>> func f(x, y int) (z int, err error)
>>>
>>> f is a function that receives x and y as int parameters, returning two 
>>> values: a first int, that we name z and an error named err. A little bit 
>>> weird, but ok.
>>>
>>> func (r MyType) f(x, y int) (z int, err error)
>>>
>>> f is a method for a value of type MyType, henceforth named r, that 
>>> receives x and y as int parameters, returning two values: a first int, that 
>>> we name z and an error named err. Definitely not so simple.
>>>
>>>  func (r genType1) f(x, y genType2) (z getType2, err 
>>> error)
>>>
>>> You must be kidding. STOP RIGHT THERE!
>>>
>>>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[ojucie]

mhh:
>Why would you put generics on a method ?

I.e.: I could have a container type and a element type to be contained.

myStack.push(myElement)

mhh:
>type Final notFinal

Maybe it is a good idea to require an intermediate type like that, to keep 
things readable.

mhh:
> none of this is as powerful as code gen.

A lot of people consider code gen a second class solution when compared to 
a more traditional generics implementation. I don't think so. Code 
generation can be very effective. No major concerns about indecipherable 
error messages. When in doubt you can inspect the generated code to 
understand exactly what is the problem.

Axel, I am very confident that no solution will be incorporated to Go 
before deep thinking about all it's implications. Your points will be 
considered, for sure.

Jesper:
>  if you don't get the above, you wouldn't have been able to pass the 
first course at my university back in the day (around 2000).

Generics user here, since Bjarne Stroustrup's CFront, the very first C++ 
compiler.

Whenever you use complex idioms you reduce the amount of people able to 
understand your code and able to mantain it. The simpler the code, the more 
people can help you.

Abuse of generics is a common source of headaches in C++ code. I saw 
seasoned developers fighting for hours or days to convince the compiler to 
grasp new code. Due to the complexity explosion things get out of control 
fast. For what? Just to throw that code away as soon as someone else needs 
to mantain it. Write-only code. 

Been there, done that. I learned it the hard way.

Today if you see a code of mine you surely will say I learned to program 
yesterday. That's exactly the way I like. People are able to read my code 
like it was a comic book. No secrets, no head scratching. I am happy, my 
employer is happy, my coworkers are happy. A lot of developers can jump to 
my project if the need/oportunity arises.

Simplicity is the single most important Go asset in my opinion, due to the 
broader audience it brings.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[mhhcbon]

simplicity is complicated: https://www.youtube.com/watch?v=rFejpH_tAHM
needlessly complex: https://youtu.be/IRTfhkiAqPw?t=19m40s
because i liked it very much: https://www.youtube.com/watch?v=QM1iUe6IofM

About code gen, as we know it in go1, i feel like it is a third class 
citizen.
In its current form i think it is not able to perform as good as it need to 
be to become a first class citizen.
being out of the language limits its capabilities. I need to find example 
about that.
Also my understanding is that it was not designed to be used for the kind 
of code gen like go-derive does it,
this usage seems to come from the community, as a workaround.
On the principles code-gen is the most capable, in practice its un-natural.

On Saturday, August 26, 2017 at 7:03:36 PM UTC+2, JuciÊ Andrade wrote:
>
> mhh:
> >Why would you put generics on a method ?
>
> I.e.: I could have a container type and a element type to be contained.
>
> myStack.push(myElement)
>
> mhh:
> >type Final notFinal
>
> Maybe it is a good idea to require an intermediate type like that, to keep 
> things readable.
>
> mhh:
> > none of this is as powerful as code gen.
>
> A lot of people consider code gen a second class solution when compared to 
> a more traditional generics implementation. I don't think so. Code 
> generation can be very effective. No major concerns about indecipherable 
> error messages. When in doubt you can inspect the generated code to 
> understand exactly what is the problem.
>
> Axel, I am very confident that no solution will be incorporated to Go 
> before deep thinking about all it's implications. Your points will be 
> considered, for sure.
>
> Jesper:
> >  if you don't get the above, you wouldn't have been able to pass the 
> first course at my university back in the day (around 2000).
>
> Generics user here, since Bjarne Stroustrup's CFront, the very first C++ 
> compiler.
>
> Whenever you use complex idioms you reduce the amount of people able to 
> understand your code and able to mantain it. The simpler the code, the more 
> people can help you.
>
> Abuse of generics is a common source of headaches in C++ code. I saw 
> seasoned developers fighting for hours or days to convince the compiler to 
> grasp new code. Due to the complexity explosion things get out of control 
> fast. For what? Just to throw that code away as soon as someone else needs 
> to mantain it. Write-only code. 
>
> Been there, done that. I learned it the hard way.
>
> Today if you see a code of mine you surely will say I learned to program 
> yesterday. That's exactly the way I like. People are able to read my code 
> like it was a comic book. No secrets, no head scratching. I am happy, my 
> employer is happy, my coworkers are happy. A lot of developers can jump to 
> my project if the need/oportunity arises.
>
> Simplicity is the single most important Go asset in my opinion, due to the 
> broader audience it brings.
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

[prades . marq]

> A lot of people consider code gen a second class solution when compared 
to a more traditional generics implementation. I don't think so. Code 
generation can be very effective. No major concerns about indecipherable 
error messages. When in doubt you can inspect the generated code to 
understand exactly what is the problem.

It's an interesting fact that when go gen was introduced, proponents of go 
gen on this very forum were swearing that it wasn't designed to be a 
solution for generics.

Code gen to make up for a lack of a feature in a type system will always be 
like building an half baked language on top of another. Code generation 
will never replace polymorphism at compile time.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and readability

['David Chase' via golang-nuts]

One distinction that might be helpful is the difference between people 
using a generic data structure
and people writing a generic data structure.  It's much more important that 
the code that makes use
of generics be readable than it is that the body of the generic be 
readable; after all, the existing generic
map implementation is a mashup of compiler and runtime stuff, and few 
people expect to be reading
that.

This does require that people who use generic data structures don't feel a 
need to grovel around in the
source code to figure out how it works.  


On Thursday, August 24, 2017 at 11:14:58 AM UTC-4, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics - Why contracts?

[jake6502]

Some of the reasons for contracts have been covered by others in this 
thread already. But somehow one of the biggest has not. Contracts make it 
possible to change the implementation of a generic function in a published 
package. Without a contract it would be super easy for a seemingly simple 
change to a published generic function to break clients of that function. 
While not foolproof, the presence of a contract means that, if the contract 
does not change, then changes to the generic code should, minimally, not 
cause compilation errors in client code. And, if intelligently created, 
should offer a degree of confidence that such changes won't functionally 
break client code either. 

Personally, I don't expect they will be hard to write. After decades of 
experience with many languages, my gut tells me that the vast majority of 
contracts written by the vast majority of "general" programmers will be 
trivial. Easily written and read. More advanced contracts would be less 
common, but I suspect that common idioms will quickly emerge for the more 
advanced constraints.

I do have some concerns about reading more complicated contracts. However, 
that can be alleviated by reasonable line commenting of complicated 
contracts. Additionally, if the error messages for violating a constraint 
when calling generic function  are well crafted, that should make it even 
easier. But I would rather have to do some extra thinking on rare occasion, 
than have to learn some whole new language for contracts. 

As for:

It runs parallel to my concerns about language compactness, too.
>
 
Again, I predict  that most contracts will be a few lines long. Secondly, 
golang is not a language of compactness. Many of the design decisions make 
that clear. And idiomatic go favors clarity over brevity. It can be hard to 
adjust to, but overall it's a win. Finally, if you are writing so much 
generic code that the contracts are any appreciable percentage of your code 
base, then you are probably way off the rails anyway. 

My 2¢


On Tuesday, September 11, 2018 at 10:57:30 AM UTC-4, Jeff wrote:

> I am a semi-advanced hobbyist. I have a BSCEE degree, but no professional 
> programming experience.  I have been programming for > 30 years and have 
> written small programs in easily 20+ different languages during that time. 
>  So, while not a professional programmer, I am not exactly a novice.
>
> I've been following some of the contracts proposal discussions and frankly 
> I have been a bit lost.  I think I have a good handle on interfaces, but 
> this contracts stuff confuses me.  One of Go's strengths is that the 
> language is relatively easy to grasp.  The code is generally relatively 
> straightforward.  People seem to draft code that leans more toward 
> readability instead of toward "clever" but less easily understood.  I have 
> looked at the source code of many packages.  It is rare that I cannot 
> follow the code.  I cannot say this about many other languages.  My fear is 
> this contracts proposal will kill my ability to read and understood code of 
> others.
>
> I recall using generics many years ago in Ada and did not recall them 
> being so confusing.  So, I went back and looked at the Ada implementation. 
>  See, e.g., https://en.wikibooks.org/wiki/Ada_Programming/Generics 
> .
>  
>  Honestly, I find this general approach to be easier to follow than 
> contracts.  Based on the link, it has some similarities with C++ templates. 
>  I have some basic experience with C++, but I have no experience with C++ 
> templates.
>
> TLDR; So why contracts and not templates or something else?  Is there a 
> benefit to contracts that I don't appreciate (very likely, cause I don't 
> understand them)?  Are there issues with a template approach?  If this has 
> been addressed elsewhere, please provide links.  I'd like a better 
> understanding as to why the Go team has chosen to explore contracts over 
> other approaches.
>
> Jeff
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics with adaptors

[Beoran]

I kind of like this idea. Contracts seem likely to introduce all kinds of 
complexity, and with a bit more explicit code, just generics without 
contracts could work just fine. It's definitely the simplest implementation 
of generics that could work.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics with adaptors

[Eric Raymond]

On Tuesday, October 16, 2018 at 6:34:10 AM UTC-4, Patrick Smith wrote:
>
> Yet another generics discussion at 
> https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302
>
> This one looks at what programmers would be able to do if very basic 
> generics were added to Go, without contracts. Generic functions may not use 
> methods or operators of their type parameters.
>
> The answer is quite a lot, actually. The code would be verbose, but not 
> impossibly so.
>

Ingenious, but  I think it fails Ian Lance Taylor's smoke test. 

I also dislike the verbosity.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics with adaptors

[alanfo]

An interesting and (for me at least) novel approach to contract-free 
generics.

Despite the suggestions towards the end, it's still too verbose for my 
taste but I did find it reassuring that, even without operator overloading 
(Eric's proposal), there would still be a plausible way to write generic 
functions which unified built-in and user defined types.

Alan

On Tuesday, October 16, 2018 at 11:34:10 AM UTC+1, Patrick Smith wrote:
>
> Yet another generics discussion at 
> https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302
>
> This one looks at what programmers would be able to do if very basic 
> generics were added to Go, without contracts. Generic functions may not use 
> methods or operators of their type parameters.
>
> The answer is quite a lot, actually. The code would be verbose, but not 
> impossibly so.
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics and parentheses

[Johann Höchtl]

watso...@gmail.com schrieb am Mittwoch, 15. Juli 2020 um 04:44:53 UTC+2:

> Guillamets are worth consideration. They are common on European keyboards 
> and avoid all the syntax ambiguities.
>
>
> They are common in the french-speaking part of europe. Even the OPs 
statement 
> A typical computer keyboard provides four easily accessible pairs of 
single-character symmetrical "brackets":
is wrong for the german keyboard layout. Now guillamets? I like the clarity 
of Golang and would not like to see it morph into APL.

-- 
You received this message because you are subscribed 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/50d4eef7-263f-4144-ab1f-797a40104397n%40googlegroups.com.

[go-nuts] Re: [generics] some questions

[T L]

Another question, how to make the following code compile:

package main

type IntSlice interface {
type []int
}

func Foo(type T IntSlice) (T) {}

func main() {
type MyInt int
Foo([]int(nil))
Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not 
found in []int)
}

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

[go-nuts] Re: [generics] some questions

[T L]

It looks the generic type argument must share the underlying type of a type 
in the constraint type list.

But the following code also fails to compile, bug?

package main

type Int interface {
type int
}

func Foo(type T Int) ([]T) {} // undefined: MyInt

func main() {
type MyInt int
Foo([]MyInt(nil))
}

On Thursday, June 18, 2020 at 7:22:51 AM UTC-4, T L wrote:
>
> Another question, how to make the following code compile:
>
> package main
>
> type IntSlice interface {
> type []int
> }
>
> func Foo(type T IntSlice) (T) {}
>
> func main() {
> type MyInt int
> Foo([]int(nil))
> Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not 
> found in []int)
> }
>

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

[go-nuts] Re: [generics] some questions

[T L]

It looks, in most cases, the current rules recommends the types shown in 
the constraint definition must be the elementary types.

On Thursday, June 18, 2020 at 7:45:52 AM UTC-4, T L wrote:

> It looks the generic type argument must share the underlying type of a 
> type in the constraint type list.
>
> But the following code also fails to compile, bug?
>
> package main
>
> type Int interface {
> type int
> }
>
> func Foo(type T Int) ([]T) {} // undefined: MyInt
>
> func main() {
> type MyInt int
> Foo([]MyInt(nil))
> }
>
> On Thursday, June 18, 2020 at 7:22:51 AM UTC-4, T L wrote:
>>
>> Another question, how to make the following code compile:
>>
>> package main
>>
>> type IntSlice interface {
>> type []int
>> }
>>
>> func Foo(type T IntSlice) (T) {}
>>
>> func main() {
>> type MyInt int
>> Foo([]int(nil))
>> Foo([]MyInt(nil)) // []MyInt does not satisfy IntSlice ([]MyInt not 
>> found in []int)
>> }
>>
>

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

[go-nuts] Re: [generics] Zero value

[Ivan Ivanyuk]

What about something like int.CreateZeroValue(), or T.CreateZeroValue() and 
CreateZeroValueInterface?

On Thursday, June 18, 2020 at 7:34:55 PM UTC+3, bruno...@gmail.com wrote:
>
> First, congratulations on the working compiler! Very cool to try out 
> generics in Go.
>
> I was experimenting  with 
> some simple generic functions and felt the need for the zero value of a 
> generic type. I've read the discussion anticipated in your proposal 
> ,
>  
> so I'd like to use this topic just to provide my sentiment, and perhaps 
> gather it from others.
>
> In my opinion, the most Go-like proposal 
>  is using '_' to signify the 
> zero value in RHS. We are already used to having '_' in LHS to accept 
> whatever type, and although the meaning is slightly changed (from 
> 'whatever' to 'zero'), it's conceptually close.
>
> I'm opposed to a change that uses '{}' or 'T{}' to mean zero type, as in 
> this proposal , because in my 
> mind curly braces are used for composite types. Imagining that 'T' is a 
> placeholder, It's weird replacing 'T{}' for 'int{}', for example. I'm super 
> in favor of having a leaner syntax for composite types, though 😁.
>
> Whatever is decided, please don't punt on this issue and recommend 
> '*new(T)'. That's really ugly and feels wrong to allocate and immediately 
> dereference the value just to circumvent a syntax change. Even if the 
> compiler is smart enough not to allocate anything, that's what's written in 
> the source code.
>
> Thanks.
>

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

[go-nuts] Re: [generics] Zero value

[Max]

Types are not first-class in Go, thus T.someMethod() is somewhat an unusual 
syntax.

The proposal  to use 'T{}' to 
mean zero value of T breaks Go compatibility promise:
if T is a map type or a slice type, 'T{}' already has a meaning:
create a non-nil, zero-elements map (or slice).
Instead the zero value of such types is nil.

Using '_' could be an elegant solution in places where type inference can 
deduce the correct type.

Two more ideas that I did not see yet are:
1. use 'T()' to mean zero value of T - currently does not compile, thus Go 
compatibility promise is preserved.
2. define a new compiler builtin 'zero(T)'

On Friday, June 19, 2020 at 1:59:59 PM UTC+2, Ivan Ivanyuk wrote:
>
> What about something like int.CreateZeroValue(), or T.CreateZeroValue() 
> and CreateZeroValueInterface?
>
> On Thursday, June 18, 2020 at 7:34:55 PM UTC+3, bruno...@gmail.com wrote:
>>
>> First, congratulations on the working compiler! Very cool to try out 
>> generics in Go.
>>
>> I was experimenting  with 
>> some simple generic functions and felt the need for the zero value of a 
>> generic type. I've read the discussion anticipated in your proposal 
>> ,
>>  
>> so I'd like to use this topic just to provide my sentiment, and perhaps 
>> gather it from others.
>>
>> In my opinion, the most Go-like proposal 
>>  is using '_' to signify the 
>> zero value in RHS. We are already used to having '_' in LHS to accept 
>> whatever type, and although the meaning is slightly changed (from 
>> 'whatever' to 'zero'), it's conceptually close.
>>
>> I'm opposed to a change that uses '{}' or 'T{}' to mean zero type, as in 
>> this proposal , because in my 
>> mind curly braces are used for composite types. Imagining that 'T' is a 
>> placeholder, It's weird replacing 'T{}' for 'int{}', for example. I'm super 
>> in favor of having a leaner syntax for composite types, though 😁.
>>
>> Whatever is decided, please don't punt on this issue and recommend 
>> '*new(T)'. That's really ugly and feels wrong to allocate and immediately 
>> dereference the value just to circumvent a syntax change. Even if the 
>> compiler is smart enough not to allocate anything, that's what's written in 
>> the source code.
>>
>> Thanks.
>>
>

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

[go-nuts] Re: [generics] Zero value

[Andrew Werner]

In order to get a zero value, does the following work today? Is it 
acceptable?

func GenericFunc(type T)() T {
return func() (t T) { return t }()
}

This could also just be written like below but above I was trying to 
demonstrate how to make a zero value within another function.

func ZeroValue(type T)() (t T) {
return t
}



On Monday, June 22, 2020 at 8:09:11 AM UTC-4, Max wrote:
>
> Types are not first-class in Go, thus T.someMethod() is somewhat an 
> unusual syntax.
>
> The proposal  to use 'T{}' to 
> mean zero value of T breaks Go compatibility promise:
> if T is a map type or a slice type, 'T{}' already has a meaning:
> create a non-nil, zero-elements map (or slice).
> Instead the zero value of such types is nil.
>
> Using '_' could be an elegant solution in places where type inference can 
> deduce the correct type.
>
> Two more ideas that I did not see yet are:
> 1. use 'T()' to mean zero value of T - currently does not compile, thus Go 
> compatibility promise is preserved.
> 2. define a new compiler builtin 'zero(T)'
>
> On Friday, June 19, 2020 at 1:59:59 PM UTC+2, Ivan Ivanyuk wrote:
>>
>> What about something like int.CreateZeroValue(), or T.CreateZeroValue() 
>> and CreateZeroValueInterface?
>>
>> On Thursday, June 18, 2020 at 7:34:55 PM UTC+3, bruno...@gmail.com wrote:
>>>
>>> First, congratulations on the working compiler! Very cool to try out 
>>> generics in Go.
>>>
>>> I was experimenting  with 
>>> some simple generic functions and felt the need for the zero value of a 
>>> generic type. I've read the discussion anticipated in your proposal 
>>> ,
>>>  
>>> so I'd like to use this topic just to provide my sentiment, and perhaps 
>>> gather it from others.
>>>
>>> In my opinion, the most Go-like proposal 
>>>  is using '_' to signify the 
>>> zero value in RHS. We are already used to having '_' in LHS to accept 
>>> whatever type, and although the meaning is slightly changed (from 
>>> 'whatever' to 'zero'), it's conceptually close.
>>>
>>> I'm opposed to a change that uses '{}' or 'T{}' to mean zero type, as in 
>>> this proposal , because in 
>>> my mind curly braces are used for composite types. Imagining that 'T' is a 
>>> placeholder, It's weird replacing 'T{}' for 'int{}', for example. I'm super 
>>> in favor of having a leaner syntax for composite types, though 😁.
>>>
>>> Whatever is decided, please don't punt on this issue and recommend 
>>> '*new(T)'. That's really ugly and feels wrong to allocate and immediately 
>>> dereference the value just to circumvent a syntax change. Even if the 
>>> compiler is smart enough not to allocate anything, that's what's written in 
>>> the source code.
>>>
>>> Thanks.
>>>
>>

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

[go-nuts] Re: [generics] Zero value

[brunokim . mc]

Yes, they work, though a simpler solution is using 'var zero T' before the 
return statement. It'd be nice to have it inline, specially for multiple 
return values.

Em segunda-feira, 22 de junho de 2020 10:13:43 UTC-3, Andrew Werner 
escreveu:
>
> In order to get a zero value, does the following work today? Is it 
> acceptable?
>
> func GenericFunc(type T)() T {
> return func() (t T) { return t }()
> }
>
> This could also just be written like below but above I was trying to 
> demonstrate how to make a zero value within another function.
>
> func ZeroValue(type T)() (t T) {
> return t
> }
>
>
>
> On Monday, June 22, 2020 at 8:09:11 AM UTC-4, Max wrote:
>>
>> Types are not first-class in Go, thus T.someMethod() is somewhat an 
>> unusual syntax.
>>
>> The proposal  to use 'T{}' to 
>> mean zero value of T breaks Go compatibility promise:
>> if T is a map type or a slice type, 'T{}' already has a meaning:
>> create a non-nil, zero-elements map (or slice).
>> Instead the zero value of such types is nil.
>>
>> Using '_' could be an elegant solution in places where type inference can 
>> deduce the correct type.
>>
>> Two more ideas that I did not see yet are:
>> 1. use 'T()' to mean zero value of T - currently does not compile, thus 
>> Go compatibility promise is preserved.
>> 2. define a new compiler builtin 'zero(T)'
>>
>> On Friday, June 19, 2020 at 1:59:59 PM UTC+2, Ivan Ivanyuk wrote:
>>>
>>> What about something like int.CreateZeroValue(), or T.CreateZeroValue() 
>>> and CreateZeroValueInterface?
>>>
>>> On Thursday, June 18, 2020 at 7:34:55 PM UTC+3, bruno...@gmail.com 
>>> wrote:

 First, congratulations on the working compiler! Very cool to try out 
 generics in Go.

 I was experimenting  with 
 some simple generic functions and felt the need for the zero value of a 
 generic type. I've read the discussion anticipated in your proposal 
 ,
  
 so I'd like to use this topic just to provide my sentiment, and perhaps 
 gather it from others.

 In my opinion, the most Go-like proposal 
  is using '_' to signify 
 the zero value in RHS. We are already used to having '_' in LHS to accept 
 whatever type, and although the meaning is slightly changed (from 
 'whatever' to 'zero'), it's conceptually close.

 I'm opposed to a change that uses '{}' or 'T{}' to mean zero type, as 
 in this proposal , because 
 in my mind curly braces are used for composite types. Imagining that 'T' 
 is 
 a placeholder, It's weird replacing 'T{}' for 'int{}', for example. I'm 
 super in favor of having a leaner syntax for composite types, though 😁.

 Whatever is decided, please don't punt on this issue and recommend 
 '*new(T)'. That's really ugly and feels wrong to allocate and immediately 
 dereference the value just to circumvent a syntax change. Even if the 
 compiler is smart enough not to allocate anything, that's what's written 
 in 
 the source code.

 Thanks.

>>>

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

[go-nuts] Re: Generics and parentheses

['gri' via golang-nuts]

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

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

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

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

[go-nuts] Re: Generics and parentheses

[Doug]

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

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

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

Thanks,
Doug

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

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

[go-nuts] Re: Generics and parentheses

[Watson Ladd]

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

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

Sincerely,
Watson 

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

[go-nuts] Re: Generics and parentheses

[Ahmed (OneOfOne) W.]

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




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

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

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

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

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

[go-nuts] Re: Generics and parentheses

[faiface2202]

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

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

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

[go-nuts] Re: Generics and parentheses

[mac3n]

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

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


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

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

[go-nuts] Re: Generics and parentheses

[Denis Cheremisov]

Great! Those multiple parenthesis were a beat on unredable side indeed, and 
I always was in the pro-square party as I always found less and greater 
signs to be unreadable. As much as I disliked Scala in general I liked 
their generic syntax. This is a really good news Go will have the same.

среда, 15 июля 2020 г. в 00:56:01 UTC+3, gri: 

> 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/dfb0b9c3-753e-4db0-822c-b73ef3225111n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[kaleidawave]

Correct me if I am wrong but wouldn't square bracket syntax have an 
ambiguity around calling a function pointer at a position in a slice:

z := []func() int{x, y};
a := z[0]();

https://play.golang.org/p/lekFJlvbRTD
On Tuesday, July 14, 2020 at 10:56:01 PM UTC+1 gri wrote:

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

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

[go-nuts] Re: Generics and parentheses

[Georges Varouchas]

Hello all,

I'd first like to say thanks to the go team for their incredible work on 
delivering such a usable tool as go.

I will then proceed to bring my 2 cents to the World Bikeshedding 
Foundation :)

I would add a vote to have something more differenciating to indicate "this 
is a generic instanciation" :

 * for generics delcaration : in both the previous spec and the "soon to be 
new" spec, the `type` keyword (in `(type ...` or `[type ...`) is a clearly 
visible marker that this is a generic type declaration
 * for generics instanciation, on the other hand : `(someType ...` or 
`[someType ...` has no easily visible indicator that this is a generic 
instanciation, rather than a list of values (when using `(`) or and 
array/map index (when using `[`)

The square brackets will be much less ambiguous, which is definitely good ;
I would still like to have a more visible thing, so that I don't have to 
think so much about the context when reading the code :
`[:` or `[!` or `[[` or ...
something which makes the places where generic types are instanciated more 
unique.

(`[!` could appear as the prefix of an index to a map with bool keys, so 
probably not this one)

Thanks for your attention,
*Georges*


Le mardi 14 juillet 2020 23:56:01 UTC+2, gri a écrit :
>
> 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 tw

[go-nuts] Re: Generics and parentheses

[dylanmeeus]

Here's my 2cents: 
I actually don't mind the parenthesis.. I've written a bunch of functions 
with them now (
https://github.com/DylanMeeus/hasgo2/tree/master/functions) and they become 
readable quickly. (Although I also enjoy LISP flavours, so maybe that 
biases my view of parenthesis :D) 

But as I can see, the square brackets do offer a certain readability 
improvement in those cases mentioned above. Somehow though the [] I 
associate more strongly with 'indexing' and 'slices / arrays' whereas with 
the `()` I don't have a strong association with a single thing. They are 
already used for multiple parts, you get

```
func (params) (return_params)
x.(string)
```

and of course for grouping mathematical operations. 

I'll play around with the change and see if I get used to them as quickly 
:) 

-- 
You received this message because you are subscribed 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/6970950d-be5e-43f6-9ea6-827d193116a5o%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[jpap]

Two thoughts:

1. How useful is it in practice to have separate start and end delimiters? 
 Does it matter for nested declarations?  I didn't see any nested 
declarations in the Draft Design document 
,
 
for example.  If allow the same token on both sides, we could use the 
vertical bar, and not require the type keyword at all:

func f(T|int|)

struct{ T|int| }

interface{ T|int| }

[]T|int|{}

type S|T| struct { v T }


(A concrete example is included at the end of this e-mail.)

The above was one of the options Matt McCullough outlined in "Towards 
Clarity: Syntax Changes for Contracts in Go 

".

2. Otherwise, could we also consider double square brackets so it becomes 
immediately obvious that the expression has nothing to do with an array? 
 (The type keyword is not needed here either.)

func f(T[[int]])

struct{ T[[int]] }

interface{ T[[int]] }

[]T[[int]]{} 

type S[[T]] struct { v T }


(The same example in this style is included at the end of this e-mail.)


On the whole, I prefer [[...]] over |...| over [...] over (...), but would 
also prefer that type declarations stick out easily enough.

jpap


PS. An example from Matt Layher 
, 
rewritten using vertical bars:

// Package hashtable implements a basic hashtable for generic key/value pairs.

package hashtable

// A Table is a basic generic hashtable.

type Table|K comparable, V interface{}| struct {

// hash is a function which can hash a key of type K with t.m.

hash func(key K, m int) int

m int

table [][]kv|K, V|

}

// A kv stores generic key/value data in a Table.

type kv|K, V| struct {

Key   K

Value V

}

// New creates a table with m internal buckets which uses the specified hash

// function for an input type K.

func New|K comparable, V interface{}|(m int, hash func(K, int) int) *Table|K, 
V| {

return &Table|K, V|{

hash:  hash,

m: m,

table: make([][]kv|K, V|, m),

}

}


PPS. The same example from Matt Layher 
, 
rewritten using [[...]]:

// Package hashtable implements a basic hashtable for generic key/value pairs.

package hashtable

// A Table is a basic generic hashtable.

type Table[[K comparable, V interface{}]] struct {

// hash is a function which can hash a key of type K with t.m.

hash func(key K, m int) int

m int

table [][]kv[[K, V]]

}

// A kv stores generic key/value data in a Table.

type kv[[K, V]] struct {

Key   K

Value V

}

// New creates a table with m internal buckets which uses the specified hash

// function for an input type K.

func New[[K comparable, V interface{}]](m int, hash func(K, int) int) 
*Table[[K, V]] {

return &Table[[K, V]]{

hash:  hash,

m: m,

table: make([][]kv[[K, V]], m),

}

}


-- 
You received this message because you are subscribed 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/3f0b6dc9-6ff1-4b20-bb09-8ef1aeb688beo%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[emetko]

Square brackets feel much better. It removes a lot of ambiguity in reading 
code. 

Actually I personally wouldn't mind to have double square brackets as 
"Generics" indicator just to remove also what little reading ambiguity they 
can cause with indices.

type A[[N]]  E


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

-- 
You received this message because you are subscribed 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/da9401a9-0c41-453e-9293-d88ee641e607o%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[rviragh]

Dear Developers:

You have spent several years on this and I'm impressed by the result, it 
looks beautiful!  I'm stunned.

As you can see from the recent spotlight shown on this syntax, in the 
meanwhile people have resorted to using unicode characters that sort of 
look like delimiters but are just part of the variable name, and then 
parsing them outside of Golang while the compiler doesn't realize the 
shenanigans that are going on with variable names that have Canadian 
Aboriginal Syllabics, resulting in a single variable name that looks like 
ImmutableTreeListᐸElementTᐳ but which contains no angle brackets.  (In fact 
here is what it looks like with angle brackets:ImmutableTreeList , 
a barely discernible difference.)

No one will soon forget this example.

I think that reflecting on the importance of visual distinction, the 
admirable step you have taken moving away from parentheses is not enough:

If [ and ] seem to work and can always be parsed unambiguously I would be 
very humbled and gracious if the designers could please show me me how the 
various examples and edge cases that have come up over the years would look 
if gofmt changed [ and ] in these places and, indeed, instead, [_ and _] 
were the standard format in these spots: 2 characters, an opening bracket 
followed by an underscore, and an underscore followed by a closing 
bracket.  (Which gofmt could convert these spots into.)

The suggestion is meant to resemble a blank spot someone has written in, as 
on a form.  The reason for letting gofmt convert it to that is to let 
people enter [ and ] at the keyboard, since you have done the hard work of 
making the spots unambiguous; this saves a character while entering at the 
keyboard, at the small expense of the formater removing a character from 
any identifier that happens to start or end with _ when used in that spot 
and using the short form syntax instead of the full gofmt syntax: in that 
case the formatter has no way of knowing that they meant to write the 
sloppy [ form for it to correct to [_ on its own.   (Since identifiers may, 
of course, both begin and end with an underscore themselves.)

*Edge Cases Because Identifiers may begin or end with an undscore (or 
both)   *

This allowance would in fact make _int_ wholly ambiguous: it could be a 
variable named _int_, or a type named int depending on where in the code it 
occurred. (If it occurred in an array index position it would refer to a 
variable.)

However, you have ensured that in fact the syntax itself makes these 
positions totally distinct even without the visual difference.   (And not 
many variables are being used which both begin and end in a _.)

Therefore at the spots where you have parsed [] as a generic, if someone 
were to enter [_int_] at the keyboard, it would be considered only as int - 
for something named _int you would have to enter [__int_] and for something 
named int_ you would have to enter [_int__], both of which seem pretty 
clear to me and an edge case that would not often come up.)

Supposing that the user were allowed to continue to enter [ and ] on the 
keyboard, since you have made the syntax unambiguous to the compiler in 
these spots, gofmt would turn them into [_ and _] wherever they refer to 
the generic syntax.

The constraint behind choosing [_ and _] is that it is visually distinct - 
always important for programmers - and unambiguous.  It is within the 
character set easily accessible by programmers and which Go already 
understands, and all Go programmers use ['s and _'s all the time.

Nobody looking at code with [_ _] can ever suppose it is anything other 
than a new syntax.

Look at the following and imagine that the [_ _] is like a form into which 
someone has entered with a typewriter:

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_]{}


I don't like different things to look the same.  [ and ] look the same as 
an array index.  They aren't an array index, so they shouldn't look like an 
array index.

But if you clever coders have made it so that it is unambiguous to the 
compiler when you mean to use the generic syntax, though you've written an 
opening or closing array limiter, then by all means let the programmer save 
having to search around for _ and allow them to use a bracket for gofmt to 
convert later.

The reference says:

Array types are always one-dimensional but may be composed to form 
multi-dimensional types.

[32]byte
[2*N] struct { x, y int32 }
[1000]*float64
[3][5]int
[2][2][2]float64  // same as [2]([2]([2]float64))


Look at that final example! [2][2][2]

I think that it would be unforutnately if some of those [ and ['s in some 
contexts can end up enclosing a type, and in other contexts enclose a 
value, depending on where you are in the parse tree, and for the programmer 
to never realize what is going o

[go-nuts] Re: Generics and parentheses

['Carla Pfaff' via golang-nuts]

I really like this square bracket syntax and I'm glad that Go does not 
repeat the mistakes other languages have made..

-- 
You received this message because you are subscribed 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/3d2d6b20-4804-4475-957b-0390511c47f8n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Hoy]

Hi,

Why do we have to allow people to write something like `w(z)` or 
`w(x,y)(z)` or `w[x,y](z)`? It's not "go-style" stuff. 
Something more in "go-style" should be:


```
wxy := w
a, b = wxy(z)
```


It is much more clear and elegant, just like what we have for error 
handling. 
In this way, brackets would not be narrowed in the same single line, thus 
being friendly to read. 
And we would not meet the ambiguity problem.

在 2020年7月15日星期三 UTC+8上午5:56:01，gri写道：
>
> 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/3a6c1c05-d716-4d13-ba7e-837ae238154eo%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Kaveh Shahbazian]

Proposals that employ the type keyword, look more Go-ish. Go is already 
doing many things differently than other PLs in C-ish family - the if 
without parentheses and no semicolon are two of things that hit most when 
switching frequently between Go and another PL.

func SomeContext() {
var aSlice [](typeㅤ T)
var aMap map[typeㅤ T](type ㅤU)
var aChannel <-chan (typeㅤ T)

aSlice = make([]int, 0)
aMap = make(map[int]int)
aChannel = make(chan int)

otherStuff(aSlice, aMap, aChannel)
}

func Action(x typeㅤ T, y, delta type ㅤU) (xres type ㅤT, yres type ㅤU) {
return
}

type Data struct {
typeㅤ T
type ㅤU

Input  T
Output U
}

type Processor interface {
Process(typeㅤ T) (Data {type ㅤT = T, typeㅤ U = string}, error)
}

type Actual struct {
type ㅤR
}

func (Actual) Process(input typeㅤ T = R) (Data{typeㅤ T = T, type ㅤU = 
string}, error) {
return Data { input, "" }
}

-- 
You received this message because you are subscribed 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/12cfbc30-4be2-47fe-a640-b8a1ffbedec2n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Alon Han]

 `generics`  looks like  a space ,
 
like c++  namespace/classSpace use `::`  `.`  `->`
and `::`  is not used in golang.


```
type A::(x,y,z) struct{ }
func f::(x,y,z)()(){}
interface  B::(x,y,z)()(){}
[]S::(x,y,z){}
```
`FOO::(x,y,z)`  just like a   `string`  for  naming .
and  the args x,y,z  are  defined without  types.




在2020年7月16日星期四 UTC+8 下午12:42:47 写道：

> Proposals that employ the type keyword, look more Go-ish. Go is already 
> doing many things differently than other PLs in C-ish family - the if 
> without parentheses and no semicolon are two of things that hit most when 
> switching frequently between Go and another PL.
>
> func SomeContext() {
> var aSlice [](typeㅤ T)
> var aMap map[typeㅤ T](type ㅤU)
> var aChannel <-chan (typeㅤ T)
>
> aSlice = make([]int, 0)
> aMap = make(map[int]int)
> aChannel = make(chan int)
>
> otherStuff(aSlice, aMap, aChannel)
> }
>
> func Action(x typeㅤ T, y, delta type ㅤU) (xres type ㅤT, yres type ㅤU) {
> return
> }
>
> type Data struct {
> typeㅤ T
> type ㅤU
>
> Input  T
> Output U
> }
>
> type Processor interface {
> Process(typeㅤ T) (Data {type ㅤT = T, typeㅤ U = string}, error)
> }
>
> type Actual struct {
> type ㅤR
> }
>
> func (Actual) Process(input typeㅤ T = R) (Data{typeㅤ T = T, type ㅤU = 
> string}, error) {
> return Data { input, "" }
> }
>
>

-- 
You received this message because you are subscribed 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/7ee85439-fa05-454f-9957-4791144b42b3n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Dominique Devienne]

On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote:

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

Nobody mentioned D's generics? https://dlang.org/spec/template.html  

The exclamation mark meaning "instantiate" reads well IMHO,
and the simpler single-type-parameter syntax omitting parens reads even 
better,
T!int is T instantiated (as in now, "at this instant"!) with int. FWIW, --DD

PS: Otherwise I agree that T[int] is nicer than T(int).

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

[go-nuts] Re: Generics and parentheses

[steven meadows]

Brackets avoid ambiguity, and allows the developer to concentrate on what 
the code is doing rather than trying to interpret it.

On Tuesday, July 14, 2020 at 5:56:01 PM UTC-4 gri wrote:

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

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

[go-nuts] Re: Generics and parentheses

[Steve Ruble]

Rather than resolving the potential ambiguities of < and > by using 
different symbols, could we use an unambiguous delimiter between the type 
parameters instead?

Consider:

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

The use of ; is not much harder to read or type than , and I think < and > 
are so close to being the "standard" syntax for generics across languages 
that it's worth adding the non-standard ; delimiter to be able to use them. 
I suppose since ; already has a meaning there might be some other ambiguity 
that it introduces, but maybe some other character would work. type 
Example struct { } seems pleasing and readable, and unlikely to 
appear in any currently valid code.


On Tuesday, July 14, 2020 at 5:56:01 PM UTC-4 gri wrote:

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

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

[go-nuts] Re: Generics and parentheses

[Tor Langballe]

The square bracket has a bit of history in go already, as a key-type 
specifier for the somwhat generics-like map declaration;

since we already do 

var map[int]string 

it feels a bit natural to specify types in square brackets to me.

-- 
You received this message because you are subscribed 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/6ea40e8b-9b1b-4e02-87bb-f60fd3e4416ao%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Mariusz Gronczewski]

Hi

pipe character isn't exactly used anywhere in Go, is on every keyboard and 
looks decent enough:

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

type Example |X,  Y| struct { }


certainly not worse than square brackets with having advantage of not being 
ambiguous to newbies or parser


-- 
You received this message because you are subscribed 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/8fa09b7a-2732-485b-bbed-a5c254205693o%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Xie Zhenye]

Gramma of a programming language is not able to be changed after released. 
So language design is elegant or not is more important than difficulty of 
implementing. 

Adding type information in parse time and use angle brackets only affects 
compiler and 3rd part tools or IDEs in a short time. Providing parser tools 
and packages can help 3rd part tools/IDE to support new gramma. And for 
professional IDE provider, process generic go code will not be more 
difficult than other language like Java, TypeScript etc.

On Wednesday, July 15, 2020 at 6:29:30 AM UTC+8 gri wrote:

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

[go-nuts] Re: Generics and parentheses

[christoph...@gmail.com]

I would like to insist on considering the D syntax using the ! for generics 
instantiation. 

The first time I saw it, I was puzzled and found it unpleasant. But this is 
just because it is unfamiliar and not intuitive.
Once I got used to it, I found it much simple than the C++ templates. In 
fact I even found it easier to use than the C++ notation.

The thing is that generic instantiation will be very frequent and most of 
the time with only one template argument. The notation using a simple ! is 
then much lighter and readable then a notation using parenthesis. 

Please, consider and favor the readability and code lightness of the most 
frequent use with generics which is the instantiation with one type 
argument.

Compare T!int  with T(int)  or T[int] or T, or A!B!int with A(B(int)) 
or A[B[int]] or A>. 

Please take the time time to experiment it and optimize the most frequent 
use. 
The D notation gave me the impression that use of generics was simple. Much 
simpler than with C++. 

Go generics made a huge and good simplification by dropping the contracts. 
Please, follow the same strategy for the instantiation of generics which 
will be the most frequent occurrence in the code.  

Le mardi 14 juillet 2020 à 23:56:01 UTC+2, gri a écrit :

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

[go-nuts] Re: Generics and parentheses

[Rei Roldan]

I agree, I prefer the D syntax as well.

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

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

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

*type Vector []!T*

Easy and readable :)

On Monday, 20 July 2020 at 16:22:08 UTC+2 christoph...@gmail.com wrote:

> I would like to insist on considering the D syntax using the ! for 
> generics instantiation. 
>
> The first time I saw it, I was puzzled and found it unpleasant. But this 
> is just because it is unfamiliar and not intuitive.
> Once I got used to it, I found it much simple than the C++ templates. In 
> fact I even found it easier to use than the C++ notation.
>
> The thing is that generic instantiation will be very frequent and most of 
> the time with only one template argument. The notation using a simple ! is 
> then much lighter and readable then a notation using parenthesis. 
>
> Please, consider and favor the readability and code lightness of the most 
> frequent use with generics which is the instantiation with one type 
> argument.
>
> Compare T!int  with T(int)  or T[int] or T, or A!B!int with A(B(int)) 
> or A[B[int]] or A>. 
>
> Please take the time time to experiment it and optimize the most frequent 
> use. 
> The D notation gave me the impression that use of generics was simple. 
> Much simpler than with C++. 
>
> Go generics made a huge and good simplification by dropping the contracts. 
> Please, follow the same strategy for the instantiation of generics which 
> will be the most frequent occurrence in the code.  
>
> Le mardi 14 juillet 2020 à 23:56:01 UTC+2, gri a écrit :
>
>> 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 
>> e

[go-nuts] Re: Generics and parentheses

[Geoff Speicher]

This is great work but compared to the rest of Go's existing syntax, I 
personally find it much harder to grok the generic code examples regardless 
of bracket choice.

It seems like a lot of complication stems from what effectively amounts to 
requiring the programmer to declare a new generic type everyplace one is 
needed. This seems like a lot of unnecessary noise, especially when you 
consider that a package is likely to reuse generic types.

What if we were to require (or at least allow/encourage) declaration of any 
generic types at the package level? Then any function or type is itself 
generic by virtue of whether or not it uses any generic types.

So instead of:

// existing proposal requires additional (type T)
// syntax for type parameter declaration
func Print(type T)(s []T) {
for _, v := range s {
fmt.Println(v)
}
}

We would have:

// declare a new package-level type, similar to "type T" but using
// a new keyword to indicate that it is generic
generic T

// Print is a generic function because T is a generic type
func Print(s []T) {
for _, v := range s {
fmt.Println(v)
}
}

The keyword generic indicates a generic type declaration, and since the 
Print function uses the generic type T, we know that Print is a generic 
function. We don't need any additional syntax at the site of the function 
definition. Type constraints can appear within the type declaration just as 
they do in the existing proposal's "inline" generic declaration.

By encouraging reuse of the generic declaration, this approach also 
encourages better choice of generic type naming instead of the ubiquitous T 
which is used almost exclusively for its brevity in inline generic type 
parameter declarations. For example:

// declare a generic type with constraint of Stringer.
// the name "Stringable" conveys more meaning than "T".
generic Stringable Stringer

// type definition requires no extra syntax for a generic type 
parameter
type StringableVector []Stringable

// method definition requires no extra syntax for a generic type 
parameter
func (s StringableVector) String() string {
var sb strings.Builder
for i, v := range s {
if i > 0 {
sb.WriteString(", ")
}
// It's OK to call v.String here because v is of 
generic type Stringable
// and Stringable's constraint is Stringer.
sb.WriteString(v.String())
}
return sb.String()
}

I don't know how this affects your implementation, but it certainly reduces 
the need for many parser changes, and eliminates the need for extra 
brackets in favor of a new keyword. It's also much easier for my aging eyes 
to read. ;)

Geoff

-- 
You received this message because you are subscribed 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/8486ccda-e42e-4332-854a-80e9b34810c7n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Bit0r Mack]

I think you can use <:T:> or <<>> or .
 Among them,  is the most convenient to input, 
because < and? Are very close on the keyboard, so you can input quickly
gri在 2020年7月15日星期三上午5:56:01 [UTC+8]寫道：

> 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/88c5ce3a-6a22-461c-abbd-3d7353a75c59n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Volker Dobler]

On Tuesday, 21 July 2020 05:06:11 UTC+2, Bit0r Mack wrote:
>
>
>  Among them,  is the most convenient to input, 
> because < and? Are very close on the keyboard, so you can input quickly
>

< and ? on my keyboard are almost the most distant keys
(_ and ° having the same distance and < and ^ being the
diagonal).

Please do not  assume everybody uses the same hardware.

V.

-- 
You received this message because you are subscribed 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/dd995eae-b575-475a-bd5d-a19e1c9470e9o%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[faiface2202]

I feel like you guys missed my suggestion earlier. I will repeat it because 
I think it can be good. What about a dot to separate type parameters in 
specialization?

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

func main() {
fmt.Println(zero.()) // . required here
}

Dot would be required in expressions when type parameters cannot be 
inferred and need to be specified manually.

I believe this fixes the syntactic ambiguities and also is consistent with 
the type assertion syntax.

What do you think?


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

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

[go-nuts] Re: Generics and parentheses

[jake...@gmail.com]

Presumably the instantiation of generic types and functions will be a lot 
more common than the declarations. How does your proposal handle those?

(FWIW, I'm fine with square brackets, or really anything other than parens.)

On Monday, July 20, 2020 at 12:42:13 PM UTC-4 Geoff Speicher wrote:

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

-- 
You received this message because you are subscribed 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/7ad301de-fe8d-4b8c-886f-7d86f8fec4d2n%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Mike Schinkel]

JMTCW: I think using square brackets [...] instead of parenthesis (...) is 
a good decision. 

And as someone whose programming experience has not been in C++ or Java, I 
always found angle brackets for generics to be rather confusing but do not 
find square brackets as confusing.  

So in my mind, good choice.

Just one person's opinion, FWIW.

On Tuesday, July 14, 2020 at 5:56:01 PM UTC-4 gri wrote:

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

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

[go-nuts] Re: Generics and parentheses

[Kaveh Shahbazian]

After playing in generics playground with a dozen of cases that came to my 
mind, IMHO brackets seem to be more clear than parentheses for declaring 
type parameters. Also using the type keyword before the type parameter 
reduces the cognitive load drastically.

type StateFn[type T] func(T) StateFn[T] // Good

vs:

type StateFn(type T) func(T) StateFn(T) // Not as clear as the previous one

It's hard to say if there are any practical alternatives to brackets - 
according to the proposal. But angle brackets are not that ugly by 
themselves.

(I'm not sure if this approach is actually possible)

The hash/number signs appear in the language specifications just once:

type StateFn<#T> func(T) StateFn<#T>

And the %T syntax is used to print types:

type StateFn<%T> func(T) StateFn<%T>

Then, that problematic example would become:

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

or:

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

On Tuesday, July 14, 2020 at 11:56:01 PM UTC+2 gri wrote:

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

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

[go-nuts] Re: generics: parametric types unmarshaling

[Zhaoxun Yan]

Here is my note on json & struct, run it somewhere and it may give you a 
hint.

package main

import "fmt"
import "encoding/json"

type prices struct{
Price   float64 `json:"price"`
floor   float64
Ceiling float64
settle  float64
timeint64
}


func main() {
content := prices{
Price:  6.4 , 
floor:  3.5, 
Ceiling:7, 
settle: 8.5,
time:   1,
}

js,_ := json.Marshal( content)
fmt.Println(string(js))

var back prices
json.Unmarshal(js, &back)
fmt.Println(back)
fmt.Println(back.Price)
}

在2022年4月14日星期四 UTC+8 16:51:22 写道：

> hi there,
>
> I am playing a bit with generics.
> I am trying to implement a parametrized "Read" function that unmarshals
> bytes into some type value that implements an interface:
>
> type T1 struct {
> v string
> }
>
> func (t *T1) UnmarshalBinary(p []byte) error {
> t.v = string(p)
> return nil
> }
>
> type Unmarshaler interface {
> UnmarshalBinary(p []byte) error
> }
>
> func f1[T Unmarshaler](p []byte) (T, error) {
> var t T
> err := t.UnmarshalBinary(p)
> return t, err
> }
>
> func main() {
> p := []byte("hello")
> t1, err := f1[T1](p)
> if err != nil {
> log.Panic(err)
> }
>
> log.Printf("t1: %+v", t1)
> }
>
> my naive attempt failed like so:
>
> ./prog.go:26:16: T1 does not implement Unmarshaler (UnmarshalBinary method 
> has pointer receiver)
>
> it's only when I rewrite my f1 function like so that it "works":
>
> func f2[T any](p []byte) (t T, err error) {
> switch t := any(&t).(type) {
> case Unmarshaler:
> err = t.UnmarshalBinary(p)
> default:
> panic("boo")
> }
> return t, err
> }
>
> but it doesn't take advantage of the nice type constraints Go's generics
> provide.
>
> of course, replacing:
> t1, err := f1[T1](p)
>
> with:
> t1, err := f1[*T1](p)
> compiles. but fails at runtime.
>
> what am I missing?
> how do I convey the constraint "unmarshaling usually imply passing a
> pointer to some value" ?
>
> -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/1679908f-db42-4eb7-88d9-1efc95ef7bbbn%40googlegroups.com.

[go-nuts] Re: [generics] generic method parameters

[Vasko Zdravevski]

Here is a working version of the Get & Set methods without changing your 
method signatures. https://go.dev/play/p/MAqFwVINvd8 

On Saturday, April 30, 2022 at 2:43:31 PM UTC-6 sunto...@gmail.com wrote:

> I've done many reading on Go generic method parameters, and it seems 
> *somewhat* supported, like from
>
> https://markphelps.me/posts/trying-out-generics-in-go/
>
> A generic Get() & Set() can be defined and used:
>
> 
> // Set sets the value.
> func (o *Optional[T]) Set(v T) {
>o.value = &v
> }
>
> ... 
>
> Now the user of my library could write code like this:
>
> o := New(42)
> v, err := o.Get()
> 
>
> However, I was having a hard time trying to apply that to my following 
> code:
> https://go.dev/play/p/p8FMYHEFRUK
>
> Is it possible to get its generic Get() & Set() function working (which is 
> currently commented out)?
>
> Thanks
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9ae2dd49-2d75-4fb9-9f98-93910c69470en%40googlegroups.com.

[go-nuts] Re: [generics] generic method parameters

[Tong Sun]

Thanks a lot sir!

On Saturday, April 30, 2022 at 4:56:44 PM UTC-4 vzdra...@gmail.com wrote:

> Here is a working version of the Get & Set methods without changing your 
> method signatures. https://go.dev/play/p/MAqFwVINvd8 
>
> On Saturday, April 30, 2022 at 2:43:31 PM UTC-6 sunto...@gmail.com wrote:
>
>> I've done many reading on Go generic method parameters, and it seems 
>> *somewhat* supported, like from
>>
>> https://markphelps.me/posts/trying-out-generics-in-go/
>>
>> A generic Get() & Set() can be defined and used:
>>
>> 
>> // Set sets the value.
>> func (o *Optional[T]) Set(v T) {
>>o.value = &v
>> }
>>
>> ... 
>>
>> Now the user of my library could write code like this:
>>
>> o := New(42)
>> v, err := o.Get()
>> 
>>
>> However, I was having a hard time trying to apply that to my following 
>> code:
>> https://go.dev/play/p/p8FMYHEFRUK
>>
>> Is it possible to get its generic Get() & Set() function working (which 
>> is currently commented out)?
>>
>> Thanks
>>
>>

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

[go-nuts] Re: Generics and "static" adapters

[Salvatore Domenick Desiano]

I guess I didn't ask an actual question... is there a more idiomatic way of 
doing this?

Thank you!

-- Salvatore
smile.


On Monday, July 24, 2023 at 4:00:59 PM UTC-4 Salvatore Domenick Desiano 
wrote:

> Ever since 1.18 came out I've been struggling to find an idiomatic way to 
> implement a certain kind of adapter. I'm starting to suspect I'm Holding It 
> Wrong (TM) so here I am.
>
> In short, I have an adapter that is effectively a collection of static 
> methods and it doesn't look right.
>
> Imagine you have a generic key-value database (transaction and life-cycle 
> methods omitted for brevity):
>
> type SimpleDatabase interface {
> Get(t ViewTransaction, key string) ([]byte, bool, error)
> Put(t UpdateTransaction, key string, value []byte) error
> }
>
> You then want to build something more specific on top using generics to 
> avoid repetition of tricky code:
>
> type ApplicationDatabase struct {
>   impl *SimpleDatabase
> }
>
> func (db *ApplicationDatabase) PutProjectRecord(t UpdateTransaction, r 
> *ProjectRecord) error {
>   return put[ProjectRecord](db.impl, projectRecordFactory, t, r)
> }
>
> type recordFactory[V any] interface {
>   dbKey(value V) string
>   encodeValue(value V) []byte
>   decodeValue(data []byte) (V, error)
> }
>
> func put[V any](db *SimpleDatabase, f *recordFactory[V], t 
> UpdateTransaction, value V) error {
>   key := f.dbKey(value)
>   valueBytes := f.encodeValue(value)
>   if err := db.put(t, key, valueBytes); err != nil 
> return fmt.Errorf("db error: %w", err)
>   }
>   return nil
> }
>
> This is nice and clean -- adding a new record type is just a matter of 
> adding a new recordFactory implementation. Adding more complexity to the 
> put/get (recovery, etc.) only has to happen once. The part that bugs me, 
> though, is that the implementation has no state and really looks like it 
> shouldn't be instantiated:
>
> type projectRecordFactory struct{}
> func (f *projectRecordFactory) dbKey() string { return  }
> func (f *projectRecordFactory) encodeValue(value V) []byte { 
> json.Marshal(...) }
> func (f *projectRecordFactory) decodeValue(data []byte) (V, error) { 
> json.Unmarshal(...) }
>
> and, frankly, if I didn't instantiate it, it would feel like either Java 
> or C++ metaprogramming.
>
> I'm open to a completely different structure but I am really hoping to add 
> new record types by adding a new package or type.
>
> Thanks!
>
> -- Salvatore
> smile.
>
>

-- 
You received this message because you are subscribed 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/318e98c2-d13e-4188-b65b-bbc7644e3ab7n%40googlegroups.com.

Re: [go-nuts] Re: Generics are overrated.

[Jan Mercl]

On Sat, Jul 29, 2017 at 3:28 PM  wrote:

> What is overrated is the use of "interface { }" and reflection AKA
runtime magics which has no place in a modern statically typed language.

interface{} is not a replacement of generics. Interfaces with a real
methods set, like sort.Interface sometimes are.

> It's a cop-out, it's dirty and a direct consequence of the absence
of generics in Go.

Not true. interface{} and reflection is, for example, used by fmt.Printf
for purpose where generics won't help. Alternatively everything must have a
Format() method. But predeclared types cannot have methods.

-- 

-j

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[prades . marq]

>
> Not true. interface{} and reflection is, for example, used by fmt.Printf 
> for purpose where generics won't help. Alternatively everything must have a 
> Format() method. But predeclared types cannot have methods.



write a compile time type safe generic *reduce *function with the following 
signature which works for all slices of any element type :

func reduce(array []A,out B,in A)B {}

you can't do that in Go .

 used by fmt.Printf for purpose where generics won't help.


Interfaces won't help either when you're basically using them as C (*void) 
. 

Le samedi 29 juillet 2017 15:38:29 UTC+2, Jan Mercl a écrit :
>
> On Sat, Jul 29, 2017 at 3:28 PM > wrote:
>
> > What is overrated is the use of "interface { }" and reflection AKA 
> runtime magics which has no place in a modern statically typed language.
>
> interface{} is not a replacement of generics. Interfaces with a real 
> methods set, like sort.Interface sometimes are.
>
> > It's a cop-out, it's dirty and a direct consequence of the absence 
> of generics in Go.
>
> Not true. interface{} and reflection is, for example, used by fmt.Printf 
> for purpose where generics won't help. Alternatively everything must have a 
> Format() method. But predeclared types cannot have methods.
>
> -- 
>
> -j
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jan Mercl]

On Sat, Jul 29, 2017 at 5:18 PM  wrote:

> write a compile time type safe generic reduce function with the following
signature which works for all slices of any element type :
>
> func reduce(array []A,out B,in A)B {}
> you can't do that in Go .

You've nonchalantly changed topic, even though no one said you can do
everything without generics. (BTW: You can, ask Mr. Turing for details.)

> Interfaces won't help either when you're basically using them as C
(*void) .

Are you really telling me you consider void*, carrying no type information
whatsoever, equal to interface{} which carries full type information? If
so, I can't help you, sorry.

-- 

-j

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Robert Melton]

On Sat, Jul 29, 2017, at 12:36, dogan.k...@dodobyte.com wrote:
> I was watching rus cox's last talk[1] and he mentioned that not every problem 
> should be solved by language change. Some can be solved by tooling or library 
> change. > 
> I am curious has any of the generics lovers written a tool that helps for 
> generic behavior. Something like,*
There are a bunch https://github.com/taylorchu/generic, 
https://github.com/cheekybits/genny, https://github.com/joeshaw/gengen, and 
https://github.com/clipperhouse/gen and I am sure many more that I don't have 
sitting in my bookmarks.
Also, building a basic one yourself if you don't want to use those tends to be 
exceptionally straightforward.  
-- 

  Robert Melton | rmel...@gmail.com



Links:

  1. https://www.youtube.com/watch?v=0Zbh_vmAKvk

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[dogan . kurt]

>
> Also, building a basic one yourself if you don't want to use those tends 
> to be exceptionally straightforward.  
>

Thanks for examples, i can't tell if they are experimental or viable for 
production use. But if it's that straightforward, why people complain about 
it too much.

I implemented hash tables a billion times in C but i never complained about 
C's lack of map type. Because i understood the design choices and 
philosophy of C. 

I always dreamed a Ken Thompson version of C++, not necessarily an object 
oriented version of C but a more modern C. C with automatic memory 
management, better string handling etc, and still small and simple. 

Now we have it, and it's called Go (Thanks to Pike, Griesemer, Cox, Taylor 
and everyone). I love it because it's small, simple, modern and it 
maintains unix's and C's philosophy. 

It just hurts me to see people try to do it what they did to C++, add 
favorite feature of everyone. I know Go team is much smarter than me and 
Thompson is the creator of unix philosophy, i am confident that Go will 
stay as it is, a small simple, pragmatic and powerful language.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Daniel]

I'm curious: are there use-cases where template generation with
gengen/genny/etc are not enough? seems to me that calling "go generate" a
few times (when you need to generate generic containers for certain types)
is a very fair tradeoff to have generic containers without having to change
the language core (or possibly affecting build times for all the other
cases that don't need them).



On Sat, Jul 29, 2017 at 1:04 PM, Robert Melton  wrote:

>
> On Sat, Jul 29, 2017, at 12:36, dogan.k...@dodobyte.com wrote:
>
> I was watching rus cox's last talk
>  and he mentioned that not
> every problem should be solved by language change. Some can be solved by
> tooling or library change.
>
> I am curious has any of the generics lovers written a tool that helps for
> generic behavior. Something like,*
>
>
> There are a bunch https://github.com/taylorchu/generic, https://
> github.com/cheekybits/genny, https://github.com/joeshaw/gengen, and
> https://github.com/clipperhouse/gen and I am sure many more that I don't
> have sitting in my bookmarks.
>
> Also, building a basic one yourself if you don't want to use those tends
> to be exceptionally straightforward.
>
> --
> Robert Melton | rmel...@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.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
"Worse things happen at sea, you know!"

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Robert Melton]

On Sat, Jul 29, 2017, at 13:33, dogan.k...@dodobyte.com wrote:
>> Also, building a basic one yourself if you don't want to use those tends to 
>> be exceptionally straightforward. > 
> Thanks for examples, i can't tell if they are experimental or viable for 
> production use. 
I am not sure the case where a code generation tool would be "experimental", as 
they aren't in most cases that clever, they are mostly just saving typing time. 
 Some of the ones listed are more clever than others -- but I would consider 
them all "production" ready in so much that they can output code you can use in 
production.

> But if it's that straightforward, why people complain about it too much.
I believe a part of it is tool anxiety.  You have to pick a tool, learn it, 
vendor it, and train others on it and hope it is maintained / improved going 
forward.  When this tool is not a blessed part of the language it often causes 
stress for people.  That said, I use a lot of console tools with Go in my day 
to day development (over a dozen no less) -- so I feel a tool for generating 
variations fits very well with the Go ethos.

-- 

  Robert Melton | rmel...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jesper Louis Andersen]

On Sat, Jul 29, 2017 at 6:36 PM  wrote:

> I just want to know sincerely, if people REALLY need generics so much, or
> they are just complaining because they are used to it and it's in their
> favorite programming language.
>
>
Generics tend to serve at least two purposes in a programming langauge.

What you are doing is that you are essentially extending functions such
that they have two types of parameters: term parameters (which is what Go
has now) and type parameters which instantiate the given function for those
types. The output type is always a term[*]. Most generics can be boiled
down to this very idea in the end and most of the notation can be reified
by expansion.

One reason to want this is simply that it avoids typing. Your example of
expanding a Max function for each possible type is a common one.

The other primary reason as to why people want something like this is
precision: you can describe the intent of a program more precisely which
means that the compiler is able to catch more programming mistakes up
front. The obvious benefit here should be when programming in the large
with many people working on the same code base. If we can capture more bugs
at compile time, they don't end up occurring when running programs.

As secondary reason is that once you start combining generic features, you
really need to start relying on the compiler telling and hinting you about
where you are mistaken in your use-case. If you had tried a variant based
on interface{} and reflect, you are likely to mess it up.

In principle, maps or arrays could have been implemented such that they
would require the use of an interface{}. But this would make more brittle
programs. Hence, the language defines maps and arrays as generic
constructions. If you look at package builtin, it defines (for
documentation purposes) builtin.Type and builtin.Type1. These are
subsequently used in different invocations where you need the invocation to
be generic: copy(), close(), append(), cap(), len(), ...

What proponents of generics are saying is that they want access to the same
kind of functionality at the language level so they can define their own
functions to work like the ones above. Clearly, the compiler must
understand the notion of generic type(!), but it doesn't give that power to
the programmer.

You can argue that Turing completeness means you can implement anything
with anything as long as it is Turing complete. But by that argument, we
could as well be writing assembly still because, after all, you can
implement anything in assembly. Programming languages are about applying
select restriction in order to achieve more. For instance by building a
programming language which doesn't make use of a goto construction, even
though assembly is all jumps and program counter manipulation.

On the other hand, it should be mentioned that Go already has an
abstraction feature in the interface construction. And some uses of
generics can be resolved simply by rephrasing them in an interface. Yet
there are certain things which cannot be expressed if you don't have a
type-level variable.

(Aside: I don't write enough Go to have an opinion on whether or not it
would be right to add generics to Go. But based on my experience with other
languages, I enjoy programming with them there. )

[*] You can explore what it means to have the output be either a term or a
type. See e.g., F* or Idris.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Shawn Milochik]

As with every community, there's the silent majority and the vocal
minority.

It's easy to be confused, and think that the lack generics is a major issue
in the Go community. It is *not*.

The number 500,000 Go developers worldwide has been thrown around a lot
this month. (https://research.swtch.com/gophercount)

Evidently most of them are using Go just fine -- as individuals, at
startups, and at huge companies.

At every scale, Go's adoption is amazing and the the projects they're
building are changing the world:

   - You don't need generics to write Docker.
   - You don't need generics to write Kubernetes.
   - We could add so much more to this list, but you get my point.

So, let's stop feeding the trolls. The far fewer than 1% of the people who
have not yet taken the time to appreciate Go for what it is, and therefore
find it lacking in comparison to something they have taken the time to
appreciate. I don't mean to belittle those people by calling them trolls,
but they are trolling. I'm sure most of them who give the language an
honest, unbiased try will come around.

Imagine if Go programmers went to other language mailing lists and
complained about the lack of goroutines and channels, which clearly make
those other language "unfit for concurrent programming." That would be
equally unhelpful.

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Jérôme LAFORGE]

> As with every community, there's the silent majority and the vocal minority.
But when we let the community to manifeste it choice (even if little part of 
this community that reply to survey) in regarding the 2016 golang survey:

What changes would improve Go most?
1 generics

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Tristan Colgate]

On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  wrote:

>
>- You don't need generics to write Kubernetes.
>
> I've had no personal need for generics, but k8s client-go is the one case
I've seen where I thought they would help, the informers packages in
particular.

https://godoc.org/k8s.io/client-go

(FWIW, I'd rather there was an effort, like the one for dep, to take
learnings from the existing generics/templating tools, and see what's
needed in the language and tooling to give us one tool in the standard tool
chain)

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Russel Winder]

On Sat, 2017-07-29 at 18:59 -0400, Shawn Milochik wrote:
> […]
> 
> Imagine if Go programmers went to other language mailing lists and
> complained about the lack of goroutines and channels, which clearly
> make
> those other language "unfit for concurrent programming." That would
> be
> equally unhelpful.

Some of us have been going round various programming language mailing
lists complaining about the lack of dataflow, CSP, etc. support in
languages and their libraries for 30+ years. 

Fortunately, over the last 10 years, we have been getting programming
language and libraries doing actors, dataflow, and CSP (or rough
equivalent) properly, and most importantly – getting traction amongst
programmers.

So now we have a number of programming language becoming fit for
concurrent and parallel programming, what is the next evolution? What
comes after Go, Rust, Pony, Nim, D, C++20, etc.?

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: This is a digitally signed message part

Re: [go-nuts] Re: Generics are overrated.

[roger peppe]

On 30 July 2017 at 08:22, Tristan Colgate  wrote:

>
>
> On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  wrote:
>
>>
>>- You don't need generics to write Kubernetes.
>>
>> I've had no personal need for generics, but k8s client-go is the one case
> I've seen where I thought they would help, the informers packages in
> particular.
>
> https://godoc.org/k8s.io/client-go
>

It's always nice to have experience reports of real world cases, so
could you expand on this, please? What specific code are you referring to
here,
and how would it be improved if Go had generics?

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Generics are overrated.

[Tristan Colgate]

Re-posting to the list.

On Mon, 31 Jul 2017, 14:15 roger peppe,  wrote:

> On 30 July 2017 at 08:22, Tristan Colgate  wrote:
>
>>
>>
>> On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  wrote:
>>
>>>
>>>- You don't need generics to write Kubernetes.
>>>
>>> I've had no personal need for generics, but k8s client-go is the one
>> case I've seen where I thought they would help, the informers packages in
>> particular.
>>
>> https://godoc.org/k8s.io/client-go
>>
>
> It's always nice to have experience reports of real world cases, so
> could you expand on this, please? What specific code are you referring to
> here,
> and how would it be improved if Go had generics?
>


I should start by saying that I'm not a contributor to client-go, just a
user,
so can't speak for their actual experience of developing that package.
As I understand it, much of client-go is generated by tools already, so
they have
the particular problem solved, and may well be far happier with what they
have than
a generics solution.

The particular package that triggered the "generics" sensation is
http://godoc.org/k8s.io/client-go/informers and
http://godoc.org/k8s.io/client-go/listers.
These generate code for efficiently watchig and listing resources on kube
cluster using
a nice cacheing mechanism.

All of the individual type specific informers packages have a

func New(f internalinterfaces.SharedInformerFactory) Interface

Interface here is a type in the package such as

type Interface interface {
// HorizontalPodAutoscalers returns a HorizontalPodAutoscalerInformer.
HorizontalPodAutoscalers() HorizontalPodAutoscalerInformer
}

which provides a type-safe way of getting at a the thing being informed on.

Part of me imagines someting like..

import hpaInformer informer

myInformer := hpaInformer.New(sharedUnderlyingCacheThing)

My hunch is that client-go has quite a few of these situations (the listers
package is one,
and general experience with the package suggests there would be others).

Clearly everything is already working pretty well, so there's nothing
"impossible" without generics here. The
client-go package is still reasonably pleasant to use (though, as a
consequence of all the genration the docs
are very verbose, but low content, it took me a long time to actually work
out how to use the shared informers
stuff because I kept start with the voluminous sub packages, rather than
the informers package that got lost in the noise).

And, once again, I'm heavily unqualified to comment on this from the
package maintainers
PoV, if they felt strongly about this, I'm sure they'd be speaking up
already.




>
>

-- 
You received this message because you are subscribed 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.
For more options, visit https://groups.google.com/d/optout.