Re: [go-nuts] [generics] Fuzzer, Type Switches

[Steven Blenkinsop]

> On Jul 18, 2020, at 9:00 PM, Ian Lance Taylor  wrote:
> 
> On Sat, Jul 18, 2020 at 3:43 PM  wrote:
>> 
>> This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ
>> 
>> Still uses interfaces internally.
> 
> Compare that to https://go2goplay.golang.org/p/8U4h9flkhFN.
> 
> Ian

Seems like this should work, but it doesn't:
https://go2goplay.golang.org/p/TtRUrLG0Cdr

The draft says:
> Writing *T instead of T in a type parameter list changes two things. Let's 
> assume that the type argument at the call site is A, and the constraint is 
> Constraint (this syntax may be used without a constraint, but there is no 
> reason to do so).
> 
> The first thing that changes is that Constraint is applied to *A rather than 
> A. That is, *A must implement Constraint. It's OK if A implements Constraint, 
> but the requirement is that *A implement it.
> 

It appears the type constraint is being applied to int instead of *int here.

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

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Ian Lance Taylor]

On Sat, Jul 18, 2020 at 4:55 AM Markus Heukelom
 wrote:
>
> Concerning the current generics proposal, was it every considered to not 
> allow type contracts at all?
>
> No type contracts would mean that generic functions can only use =, & on 
> variables of parametric types, as these are always available for all types. 
> Nothings else is allowed.
>
> This would remove the possibility to write generic mathematical functions, 
> for example. But it is simple and it already enables a lot of usefulness. Was 
> this considered too restrictive?
>
> Type contracts could optionally be added in a later stage, but at least at 
> that point we will have a larger body of generic code to work and test with.
>
> A bonus, disallowing all operations except assignment and address-taking 
> would maybe also stop abuse of templates in the name of "but it is more 
> efficient than interfaces" and "fancy coding syndromes".

I think that for a language like Go any generics implementation must
permit people to write the functions Min and Max.  The functions are
trivial, but they are among the first that programmers accustomed to
generics complain about in Go.

Ian

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

Re: [go-nuts] [generics] question regarding package level generic type declarations

[Ian Lance Taylor]

On Sat, Jul 18, 2020 at 4:00 AM Markus Heukelom
 wrote:
>
> Concerning only the current proposal, is there a reason why we shouldn't 
> allow specifying the parametric types for a whole bunch of functions / types 
> at once?
>
> Like:
>
> generic (type T) (
>
> func Average(value []T) {...}
> func Median(value []T) {...}
> // etc
> )
>
> generic (type T1, T2) (
>
> func Map(s []T1, func(T1) T2) []T2
> func BiMap(s []T1, func(T1) T2) []T2
> //...
> )
>
>
> All things within generic () would have the same type parameter signature. It 
> would be a bit similar to how var and const declarations work. It would 
> remove a lot of redundancy and parenthesis.
>
> To make things symmetric, a single generic function would have to be 
> specified with something like this
>
> generic (type T1, T2) func Map(s []T1, func(T1) T2) []T2.
>
> type Vertex generic (type T) struct {
>  Coords [3]T
> }


How do we instantiate these generic types and functions?  If a list of
generic type parameters is factored out, do we have to supply all of
them even if a particular function only uses one of them?

Also, while this may seem like a trivial question, how do we indent
within a generic block?

(To answer your question, we did actually look at syntactic approaches
along these lines for a while, but we eventually moved on to the ideas
presented in the design draft.  Not because this idea is terrible, but
because we felt the approach used in the design draft was a better fit
for the language.)

Ian

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

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Sat, Jul 18, 2020 at 12:19 AM Tyler Compton  wrote:
>
> I'm beginning to think that community members (like myself) can't reasonably 
> be expected to put in the necessary effort to champion a sizable language 
> change. I think it was Ian who made multiple generics draft proposals just to 
> reject them himself, then Ian and Robert Griesemer spent more untold hours 
> writing the contracts draft design only to have that rejected as well. For 
> people outside the core Go team, these probably would have been unpaid hours. 
> It's hard to justify spending that kind of time when there's such a high 
> chance that the proposal may not amount to anything. I think it's for this 
> reason that community proposals are usually nowhere near as fleshed out as 
> the draft proposals we've been getting from the core team.

In fairness, though, there is no language change proposal that is as
large as generics.  The changes that were made in recent releases were
much smaller.  (And, for what it's worth, they did not all come from
Googlers; e.g., https://golang.org/issue/12711,
https://golang.org/issue/19308, https://golang.org/issue/29008.)

Ian

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

Re: [go-nuts] [generics] Fuzzer, Type Switches

[Ian Lance Taylor]

On Sat, Jul 18, 2020 at 3:43 PM  wrote:
>
> This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ
>
> Still uses interfaces internally.

Compare that to https://go2goplay.golang.org/p/8U4h9flkhFN.

Ian

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

Re: [go-nuts] Generics and parentheses

[Laurens Hellemons]

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

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

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

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


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

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

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

Re: [go-nuts] Go 2 review process

[David Skinner]

While I have over 50 years of programming experience, I am also quite old 
and sometimes have senile moments.

I once wrote an extremely well-written bug report complaining about the use 
of the backtick which is not on my keyboard, explained why it should not be 
used, and then presented a workaround involving ANSI escape codes to enter 
the character which was not on the keyboard. The response was immediate and 
quite positive as everyone thought it was a marvelous satire on newbies who 
suggest language changes without understanding Go first. However, my eldest 
son Daniel, called me on the phone to remind me that the backtick was in 
fact on my keyboard just below the ESC key. He also asked me not to comment 
on Go-nuts on a bad day.

Anyone who does not like a Go syntax can do what I do, I write my code the 
way that I write code in Davsk, then I compile/refactor that into Go code. 
I have enum, ternary, generics,  whatever I want but the implementation is 
in Go. I am someone who does not believe in writing a lot of code, I prefer 
to do a domain-specific definition of a problem and then compile my 
definition into implementation, and the implementation in Go is performant 
and adequate.

The disadvantage of my approach is that I am using the same high-level 
language I used 40 years ago. Great for me, bad for everyone else.

The Go2 preprocessor that lets you test generics syntax is precisely the 
kind of solution that I approve of, but we cannot have a plethora of 
standards or we lose readability. GOFMT was a godsend for standardization 
even if I did not agree with all of the decisions, someone had to make the 
decision and then the decision had to be enforced.

I need for Go to remain standard and unchanging, fast when compiling and 
linking, fast when running, small footprint, cross-platform, not because I 
use it to write my programs, but because I use it to compile my programs 
which some else who does understand go will be able to comprehend.

The generic proposal with a plethora of ()()() resulted in a stack overflow 
for my parser which is implemented in wetware, my eyes saw it all but with 
or without spaces, just not intuitive in my brain, it lacks readability. 
Code is written once, read many
I prefer the Clojure method of handling generics, I do not mind <>, not 
sure about [], gen keyword is a favorite for me. I can adapt to whatever 
the community decides. 

Error handling can certainly be cleaner but what we have so very versatile, 
I would hate it if you broke my old libraries. 

"Maybe the ONLY allowed issues going forward should be experience reports 
and clear identification of problems/pain points (which have always been 
requested but are probably the minority of user contributions?), and maybe 
some process for community input/voting for how significant those issues 
are (as Max suggested)."

I am totally in favor of the Go team making the final decisions, they have 
my respect and trust. But of course, the real final decision is made in the 
marketplace by the developers who choose to use or not use the language.

On Saturday, July 18, 2020 at 4:05:18 PM UTC-5 Randall Oreilly wrote:

>
> > On Jul 16, 2020, at 3:35 PM, Ian Lance Taylor  wrote:
> > 
> > The language is stable and is not looking to change in any
> > significant way (except perhaps for adding generics). We've realized
> > that we need to be upfront about that. 
>
> The Go2 process certainly created the expectation that the language was 
> looking to change. But I guess the point here is that this window is now 
> closing? Maybe it would be good to have a new blog post to that effect?
>
> Expectation management is very important -- if we all recognize and accept 
> that Go is a fixed language that will never change, then nobody will be 
> disappointed when it doesn't!
>
> And why should it change? This idea that languages should constantly be 
> evolving may not make any sense: once a language is Turing complete, and 
> highly effective, supporting millions of happy, productive coders, it could 
> just be done. People can invest time and energy in writing code and tools, 
> not changing the language.
>
> I guess the only two major pain points that are widely discussed are 
> generics and error handling, and it looks like we'll get a good solution 
> for the first, and who knows about the second at this point?
>
> Maybe the ONLY allowed issues going forward should be experience reports 
> and clear identification of problems / pain points (which have always been 
> requested, but are probably the minority of user contributions?), and maybe 
> some process for community input / voting for how significant those issues 
> are (as Max suggested).
>
> - Randy
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on 

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

[Vasiliy Tolstov]

пт, 17 июл. 2020 г. в 05:40, Justin Israel :
>
>
>
> On Friday, July 17, 2020 at 11:21:32 AM UTC+12 va...@selfip.ru wrote:
>>
>> вт, 14 июл. 2020 г. в 18:39, Jake Montgomery :
>> >
>> > I agree, it seems like an unfortunate oversight. You can do it without the 
>> > slice tricks: https://play.golang.org/p/tNAPOcQqApN
>> > It does take an additional Sprintf() though.
>> >
>>
>> Thanks, looks good. But i think for go devs adding additional format
>> that can be used to specify milli/micro/nano seconds will be easy.
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.to...@selfip.ru
>
>
> I asked the same question on reddit about a month ago, where I needed to 
> match an existing timestamp format:
> https://www.reddit.com/r/golang/comments/gr7hz9/string_formatting_a_timetime_with_custom/
>
> Seems string formatting was the best option available to me.
>

Yes, this is bad case for stuff that works with many messages and
want to avoid additional memory allocations

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

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

[go-nuts] [generics] Fuzzer, Type Switches

[uluyol0]

This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ

Still uses interfaces internally.

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

Re: [go-nuts] Go 2 review process

[Randall Oreilly]

> On Jul 16, 2020, at 3:35 PM, Ian Lance Taylor  wrote:
> 
> The language is stable and is not looking to change in any
> significant way (except perhaps for adding generics).  We've realized
> that we need to be upfront about that.  

The Go2 process certainly created the expectation that the language was looking 
to change.  But I guess the point here is that this window is now closing?  
Maybe it would be good to have a new blog post to that effect?

Expectation management is very important -- if we all recognize and accept that 
Go is a fixed language that will never change, then nobody will be disappointed 
when it doesn't!

And why should it change?  This idea that languages should constantly be 
evolving may not make any sense: once a language is Turing complete, and highly 
effective, supporting millions of happy, productive coders, it could just be 
done.  People can invest time and energy in writing code and tools, not 
changing the language.

I guess the only two major pain points that are widely discussed are generics 
and error handling, and it looks like we'll get a good solution for the first, 
and who knows about the second at this point?

Maybe the ONLY allowed issues going forward should be experience reports and 
clear identification of problems / pain points (which have always been 
requested, but are probably the minority of user contributions?), and maybe 
some process for community input / voting for how significant those issues are 
(as Max suggested).

- Randy



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/73C21F61-EC5E-4649-A3C8-61354317A005%40colorado.edu.

Re: [go-nuts] Generics and parentheses

[Jakob Borg]

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

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

//kb

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

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

Jon

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


From: Yaw Boakye mailto:wheres...@gmail.com>>
Sent: Saturday, July 18, 2020 10:43:11 AM
To: Jon Conradt mailto:j...@theconradts.com>>
Cc: golang-nuts 
mailto:golang-nuts@googlegroups.com>>
Subject: Re: [go-nuts] Re: Generics and parentheses

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

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

Jon

On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote:
>
> Guillamets are worth consideration. They are common on European keyboards and 
> avoid all the syntax ambiguities.

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

Ian

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


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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/F6A41A04-BDBC-46C2-A8C9-0B8D19BF4DC5%40kastelo.net.

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

[Viktor Kojouharov]

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

On Friday, July 17, 2020 at 5:56:32 PM UTC+2, Jon Conradt wrote:
>
> In the spirit of “show me, don’t tell me” and experience reports. How hard 
> would it be to release a beta which supports both [] and guillamets? We try 
> them. We see where we have compatibility problems. We give editor writers 
> and plugin writers a chance to simplify they keystrokes?
>
> Jon
>
> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>
>> On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote: 
>> > 
>> > Guillamets are worth consideration. They are common on European 
>> keyboards and avoid all the syntax ambiguities. 
>>
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use
>>  
>>
>> Ian 
>>
>

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

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

[Jon Conradt]

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

Jon

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


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

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

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

Jon

On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote:
>
> Guillamets are worth consideration. They are common on European keyboards and 
> avoid all the syntax ambiguities.

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

Ian

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


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

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

Re: [go-nuts] Generics and parentheses

[Kiswono Prayogo]

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

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

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

Re: [go-nuts] Generics and parentheses

[goldenbull]

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

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

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

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

[Steve Jones]

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

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

> I don't know if the recommendation to use guillamets is out of spite for 
> the ongoing deliberations. But if it's a serious recommendation, then can 
> some recommend where I can buy one of these European keyboards? On top of 
> that, I could start a business selling European keyboards to Go programmers 
> in Africa who want to use generics, where American keyboards (or keyboard 
> with mostly ASCII characters) are common.
>
> On Fri, Jul 17, 2020 at 4:56 PM Jon Conradt  wrote:
>
>> In the spirit of “show me, don’t tell me” and experience reports. How 
>> hard would it be to release a beta which supports both [] and guillamets? 
>> We try them. We see where we have compatibility problems. We give editor 
>> writers and plugin writers a chance to simplify they keystrokes?
>>
>> Jon
>>
>> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>>
>>> On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote: 
>>> > 
>>> > Guillamets are worth consideration. They are common on European 
>>> keyboards and avoid all the syntax ambiguities. 
>>>
>>>
>>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use
>>>  
>>>
>>> Ian 
>>>
>> -- 
>>
> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> *Curried programmer*
> *Homepage*: http://yawboakye.com
> I'm tweeting  when I'm not coding 
>  when I'm not holding my niece.
>

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

Re: [go-nuts] the go archive size must be smaller？

[Jake Montgomery]

You are asking about the size of the archived go distributions, NOT about 
the size of programs built with go, correct?

On Friday, July 17, 2020 at 5:33:31 PM UTC-4, yangw...@gmail.com wrote:
>
> This issue is only the binary file, I said is go archive size .
> Such as go1.14.6.darwin-amd64.tar.gz 
>  or 
> go1.14.5.darwin-amd64.tar.gz 
> 's size etc.
>
> 在2020年7月17日星期五 UTC+8 下午5:38:04 写道：
>
>> Note that progress for reducing binary size is tracked under this issue: 
>> https://github.com/golang/go/issues/6853
>>
>

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

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

[Yaw Boakye]

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

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

> In the spirit of “show me, don’t tell me” and experience reports. How hard
> would it be to release a beta which supports both [] and guillamets? We try
> them. We see where we have compatibility problems. We give editor writers
> and plugin writers a chance to simplify they keystrokes?
>
> Jon
>
> On Tuesday, July 14, 2020 at 11:37:21 PM UTC-4 Ian Lance Taylor wrote:
>
>> On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote:
>> >
>> > Guillamets are worth consideration. They are common on European
>> keyboards and avoid all the syntax ambiguities.
>>
>>
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/af5929bc-2e49-48dc-a1bc-3a9a7ef63051n%40googlegroups.com
> 
> .
>


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

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

Re: [go-nuts] Generics and parentheses

[roger peppe]

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

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


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

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

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

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


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

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

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

What if S isn't a struct type?


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


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

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

Which compromises are you referring to here?


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


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

And

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

Re: [go-nuts] Generics and parentheses

[Jan Mercl]

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

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

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

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

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

Ok, I think now I understand better.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Very subjective, but it makes sense to 

Re: [go-nuts] [generics] Was "no type contracts" considered?

[Jesper Louis Andersen]

On Sat, Jul 18, 2020 at 1:55 PM Markus Heukelom 
wrote:

> Concerning the current generics proposal, was it every considered to not
> allow type contracts at all?
>
> No type contracts would mean that generic functions can only use =, & on
> variables of parametric types, as these are always available for all types.
> Nothings else is allowed.
>
>
I've written a lot of code in this style in Standard ML. In fact, SML
distinguishes between types and eqtypes, where the latter allows for
equality comparisons. Many types do not have an equality check defined on
them, most notably floating point values and functions among the ground
types.

The place where you hit the limitation is usually when you have an ordered
tree and you need a function `cmp` of type `'k -> 'k -> order` which can
order the keys in the tree. When you construct the tree, you have to
provide such an ordering function and embed the order in the data structure
of the tree. It is usually nicer to have that order implicitly bound to the
type, especially for trees where you don't require a specific order, only
some order that is total (or perhaps well-ordered).

Standard ML gets around this limitation by the means of "Functors" which
are functions from modules to modules. In Go-parlance that would be
generics on the package level, which I believe has been explored. My guess
is that to make this efficient in writing, you also need to have nested
packages, something which Standard ML has, but Go doesn't. Functors are
also a nominal construction, whereas Go tends to use structural
constructions where possible.

The current Go solution is closer to Haskell, where you can write the
signature for the insertion into a tree as

insert :: Ord k => k -> a -> Map k a -> Map k a

that is, given a key, k, a value of type a, and a map for those types,
produce a map where the K/V pair has been inserted. The `Ord k => ...` part
constrain the type `k` to be ordered.

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

[go-nuts] [generics] Was "no type contracts" considered?

[Markus Heukelom]

Concerning the current generics proposal, was it every considered to not 
allow type contracts at all?

No type contracts would mean that generic functions can only use =, & on 
variables of parametric types, as these are always available for all types. 
Nothings else is allowed.  

This would remove the possibility to write generic mathematical functions, 
for example. But it is simple and it already enables a lot of usefulness. 
Was this considered too restrictive?

Type contracts could optionally be added in a later stage, but at least at 
that point we will have a larger body of generic code to work and test 
with. 

A bonus, disallowing all operations except assignment and address-taking 
would maybe also stop abuse of templates in the name of "but it is more 
efficient than interfaces" and "fancy coding syndromes".

-Markus

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

Re: [go-nuts] Generics and parentheses

[roger peppe]

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

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


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

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

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

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

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

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

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

S@string@int

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

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

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


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


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

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

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

Re: [go-nuts] [generics] question regarding package level generic type declarations

[Markus Heukelom]

Thanks for the answer.

Concerning only the current proposal, is there a reason why we shouldn't
allow specifying the parametric types for a whole bunch of functions /
types at once?

Like:

generic (type T) (

func Average(value []T) {...}
func Median(value []T) {...}
// etc
)

generic (type T1, T2) (

func Map(s []T1, func(T1) T2) []T2
func BiMap(s []T1, func(T1) T2) []T2
//...
)


All things within generic () would have the same type parameter signature.
It would be a bit similar to how var and const declarations work. It would
remove a lot of redundancy and parenthesis.

To make things symmetric, a single generic function would have to be
specified with something like this

generic (type T1, T2) func Map(s []T1, func(T1) T2) []T2.

type Vertex generic (type T) struct {
 Coords [3]T
}

On Fri, Jul 17, 2020 at 8:26 PM Ian Lance Taylor  wrote:

> On Fri, Jul 17, 2020 at 1:56 AM Markus Heukelom
>  wrote:
> >
> > The authors of the current generics proposal mention that they looked
> into doing generics only on package level:(
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages
> )
> >
> > I understand the reasons what it wasn't pursued further.
> >
> > Did the authors investigate the possibility of declaring generic types
> on a package level instead of per type/function? Ie.
> >
> > generic T {}
> >
> > func Max(a, b T) T {}
> > func Min(a, b T) T {}
> >
> > I wrote down an idea on this, that is admittingly a bit wild (or naive)
> or maybe impossible from a parsing perspective. But I'd like to validate
> the main idea behind it.
> >
> > My whole attempt was based on the observation that most packages that
> will include generic functionality, will only really need one or maybe a
> couple of generic type constraints.
> >
> > For example, if you look at a hypothetical statistics package, there
> will be many, many functions that compute stuff on slices of T, where T
> must be a number. So there will be many functions like:
> >
> > type Number interface { // using currently proposed generics
> > type int, float64, // etc
> > }
> >
> > func Average(type T Number)(values T...) T {} // using currently
> proposed generics
> > func Median(type T Number)(values T...) T {}
> > func Binonimal(type T Number)(values T...) T {}
> > // etc etc etc
> >
> > My point is that the "(type T Number)" part in all the declarations /
> definitions become really redundant from a human perspective, just because
> a package will naturally (should?) only use 1 or at most a couple of
> generic types. That would make it, at least theoretically, possible to
> write something like
> >
> > type Number interface {
> > int, float64, // etc
> > }
> > generic T Number
> >
> > func Average(values T...) T {}
> > func Median((values T...) T {}
> > // etc
> >
> > Coincidentally, the builtin language sort of uses this idea in its
> documentation.
> >
> > Another (theoretic) possibility would be something like this:
> >
> > generic T Number ( // analog to multiple const or var declarations
> > func Average(values T...) T {}
> > func Median((values T...) T {}
> > )
> >
> > My question is: did the authors investigate something like this, or is
> it plainly impossible or undesired?
> >
> > For those interested, my proposal can be found here:
> https://github.com/golang/go/issues/39716. I use the key word "meta"
> there instead of "generic".
>
> Thanks for the note.
>
> Yes, we looked at ideas like that.  It's unclear how to handle this
> area at the point where we want to instantiate the generic function or
> type.  How do we pass the type argument?  If there is a single generic
> type parameter it's not so bad, but there are many simple examples
> that require multiple type parameters, such as the Map function on
> slices:
>
> func Map(type T1, T2)(s []T1, func(T1) T2) []T2
>
> There should be some natural way for the caller to write Map(int,
> string) to get a value whose type is
>
> func([]int, func(int) string) []string
>
> If generics are defined at the package level, how do we do that?
>
> If the answer is that you specify the type arguments when you import
> the package, then how do handle List(List(int))?
>
> Ian
>

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

Re: [go-nuts] Generics and parentheses

[bugpowder]

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

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


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

I'd say that introducing special-purpose symbols instead of re-using the
same undifferentiated constructs used elsewhere in the language just with a
string qualifier like "type" added makes it easier to read, and not lose it
in the sameness of declaring parameter lists and return types, etc.

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

Re: [go-nuts] Generics and parentheses

[Jan Mercl]

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

Thanks for taking time to think about it.

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

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

var a = 42

a := 42

func f(a int)  {...}

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

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

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

var a T
var a $T

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

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

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

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

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

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

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

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

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

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

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

Example from the alternative draft, page 2:

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

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

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

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

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



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

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

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

[Jan Mercl]

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

It's the bitwise binary or operator.

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

[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

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

Re: [go-nuts] Generics and parentheses

[roger peppe]

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

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


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

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

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

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

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

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

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

  cheers,
rog.

I haven't made any
> attempt to write a parser for the alternative draft, but I think this
> makes the changes on top of the existing parser pretty minimal. The
> original draft, on the other hand, needs IMO much more changes.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-VwE2URengdE0Cd7sPQNCm5%3DTm5%3DaUS8kMwOpEw%3DXjJyg%40mail.gmail.com
> .
>

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

Re: [go-nuts] Go 2 review process

['Axel Wagner' via golang-nuts]

There seems to be an assumption that, given enough time and effort, any
idea could get accepted into the language. But that clearly can't be so. It
might be frustrating to hear that your particular idea just isn't
considered a good idea, but it's a necessity that most ideas go that route.
It's not a question of how much you flesh it out or how much developmental
feedback it gets - most ideas just won't end up in the language.

I think so far the Go team has done an incredible job at triaging and
discussing any idea, even if I felt it clearly wouldn't make it. I totally
understand if they are being more direct and brief in the future :)

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

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

[Jan Mercl]

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

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

That requires an unbound lookahead which is better avoided.

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

Re: [go-nuts] Go 2 review process

[Max]

I have a proposal for improving Go proposal procedure.

It stems from two "issues" highlighted in several occasions:

   1. core Go team is spending an increasing amount of time discussing a 
   larger number of proposals.
   All of them are commented and discussed by core Go team, and in the end 
   most of them are declined.
   
   2. participation of Go community at large to the proposal procedure is 
   limited:
   single individuals can create new proposals or comment on them, but 
   there is no concept of "community support" or "community effort"

In short, there is no *filter* between single individuals and core Go team.
Direct communication is good in a small group, but it does not scale to 
large groups.

My proposal is conceptually simple:
delegate some power (rights) and responsibility (duties) to the 
community.

How? I propose the following:

1. proposals must collect enough "community support" before being evaluated 
by core Go team.
   Initially, this can be as simple as waiting for enough thumbs up (and 
fewer thumbs down) on the corresponding github issue.
   If/when need arises, it may also become a more formal process.

   The core Go team will have less work:
 they would be *required* to evaluate only those with enough "community 
support", not *all* proposals as they do now.
 Of course they will still be free to evaluate also other proposals if 
they want, but they will not be required to.

   The Go community would be empowered by this change:
 it will have a more active role, acting as a first filter for 
proposals,
 and a proposal with strong community support should receive more focus 
from core Go team
 than a proposal with weak (or no) community support.

   This may require a web page that lists active proposals (is it allowed 
to scrape github content?),
   with mechanisms to filter them by keyword(s) and sort them at least by 
date/thumbs up/thumbs down.

2. proposals must follow a template, which contains at least:
 
   a. the list of existing similar proposals and, if they were not 
approved, the reasons why the new proposal
  is believed to be better
 
   b. a first evaluation of pros and cons

   This is expected to improve the quality of new proposals, by doing a 
basic background check of prior art
   and a first (self) evaluation.



On Friday, July 17, 2020 at 7:54:46 PM UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Jul 17, 2020 at 10:20 AM medienwer...@gmail.com 
> > wrote: 
> > 
> > With your considerations in mind I suggest a well defined triage 
> mode/"traffic light" - system for processing language feature proposals. 
> > 
> > When your/the teams bias is clear, the indication shows the proposer/the 
> community feasible and/or practicable "next steps". 
> > 
> > Also a collection of "reference cases" can guide the growing number of 
> gophers, viable ideas and solutions. 
> > 
> > Following posts explain the needs: 
> > 
> > https://blog.golang.org/toward-go2 
> > 
> > https://blog.golang.org/experiment 
> > 
> > https://blog.golang.org/go2-here-we-come 
>
> Thanks for the suggestion.  However, I don't understand how to make 
> that work in practice.  Who is going to take the time to show feasible 
> and practical next steps for each proposal?  How is that different 
> from what we have been doing for the last year? 
>
> Ian 
>

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

Re: [go-nuts] Go 2 review process

[Tyler Compton]

I'm beginning to think that community members (like myself) can't
reasonably be expected to put in the necessary effort to champion a sizable
language change. I think it was Ian who made multiple generics draft
proposals just to reject them himself, then Ian and Robert Griesemer spent
more untold hours writing the contracts draft design only to have that
rejected as well. For people outside the core Go team, these probably would
have been unpaid hours. It's hard to justify spending that kind of time
when there's such a high chance that the proposal may not amount to
anything. I think it's for this reason that community proposals are usually
nowhere near as fleshed out as the draft proposals we've been getting from
the core team.

There are some incredibly talented and persistent gophers out there and I
don't mean to discourage them. This is just my observation from the
community proposals I've read.

On Thu, Jul 16, 2020 at 1:32 PM Brandon Bennett  wrote:

> I have just read
> https://github.com/golang/go/issues/33892#issuecomment-659618902 and
> since it was posted on a closed issue I wanted to comment a bit more.
>
> I subscribed to this issue and read the updates for both the Go2 proposals
> as well as the Go1 proposals and I enjoy reading them.  I understand the
> reasoning behind wanting to do less here but I do belive there are some
> downsides as well.
>
> One reason I read these every week is that it gives people outside of the
> Go team an insight into the thought process and the reasoning of
> decisions.  Also feedback on these changes hopefully should help to refine
> future requests.  I am really afraid that just "ignoring" requests
> continues or goes back to the idea that  that Go is not a community
> language and that the only ideas and changes can come from Google employees
> (or past employees in the case of bradfitz).  The transparency here was
> awesome and I am very sad to see it go away.
>
> I hope there is some other middle ground or at least some details around
> what will go into hand picking?  For the non-picked proposals will they
> just remain open for some undetermined amount of time?  Will they just be
> closed?  Is feedback on these still expected?   Maybe the real solution is
> just to meet up less?  Maybe once a month or even once a quarter vs every
> week?
>
> Thank you,
>
> Brandon
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6e012c05-24ce-49cf-a8f2-b8b6f3f543ffo%40googlegroups.com
> 
> .
>

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