Re: [go-nuts] Re: Considering dropping GO386=387

['Hunter Herman' via golang-nuts]

Thank you! 

Ian Lance Taylor  wrote:

“On Fri, Jul 17, 2020 at 12:54 AM Hunter Herman  wrote:

>

> Hi Austin! I’m very curious about the register based calling convention you 
> referenced in your email. Could you share more (informal is fine) details?



See https://golang.org/issue/18597 and https://golang.org/issue/27539.



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/d0a3f82622f1a1a4631fdaecc4d36f23c7774236%40hey.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 

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

[Goodwine Carlos]

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

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

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

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

Re: [go-nuts] Pointers to allocated memory objects?

[Michael Jones]

interior.

https://blog.golang.org/ismmkeynote

On Fri, Jul 17, 2020 at 7:57 PM joe mcguckin 
wrote:

> Do pointers have to point to the beginning of a heap object or can they
> point to the interior of the object?
>
> Thanks,
>
> Joe
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To 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/67380fb0-4677-471a-8fce-fb7073ff0a07o%40googlegroups.com
> 
> .
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

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

[go-nuts] Pointers to allocated memory objects?

[joe mcguckin]

Do pointers have to point to the beginning of a heap object or can they 
point to the interior of the object? 

Thanks,

Joe

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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/67380fb0-4677-471a-8fce-fb7073ff0a07o%40googlegroups.com.

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

[Michael Jones]

What are you asking for?

1. GZip to compress more completely?
2. Use of different compression tools? (Zstd?)
3. Go to output binaries that are more compression friendly?
4. The Go binaries to just be smaller?
:

If you are specific, you will get specific answers.

On Fri, Jul 17, 2020 at 2:33 PM 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/dd1edcfe-698b-4005-be0e-56083c35878fn%40googlegroups.com
> 
> .
>
-- 

*Michael T. jonesmichael.jo...@gmail.com *

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

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

['Dan Kortschak' via golang-nuts]

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

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

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


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

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

[Jay Kay]

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

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

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

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

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

[yangw...@gmail.com]

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/dd1edcfe-698b-4005-be0e-56083c35878fn%40googlegroups.com.

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

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 12:36 PM Josh Hoak  wrote:
>
> I was playing around with trying to use generics to de-interface-ify a fuzzer 
> implementation, and I ran into some stumbling blocks.
>
> is it possible to perform type switches? It seems the answer is currently no 
> (example, design doc reference). Maybe there's a better way to handle the 
> following?
>
> type Primitive interface {
>   type int, string
> }
>
> func Randomize(type F Primitive)(f F, r *rand.Rand) F {
>   switch v := (interface{})(f).(type) {
>   case string:
> return fmt.Sprintf("%s--%d", v, r.Int())
>   case int:
> return v + r.Int()
>   default:
> panic(fmt.Sprintf("I don't know about type %T!\n", v))
>   }
> }
>
> func main() {
>   r := rand.New(rand.NewSource(1))
>   fmt.Println(Randomize(int)(1, r))
> }

Yes, there currently is no way to switch on the underlying type of the
type argument, as discussed in the part of the design draft that you
link to.

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/CAOyqgcVPQDOiVKx%2BDD1%3DREf2OK4HcRgOjXkEiyrsPjXsxQG93Q%40mail.gmail.com.

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

[Patrick Kelly]

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

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

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

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

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

> On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote:
> >
> > Guillamets are worth consideration. They are common on European 
> keyboards and avoid all the syntax ambiguities.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use
>
> Ian
>

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

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

['Carla Pfaff' via golang-nuts]

Why not write two functions?

On Friday, 17 July 2020 at 21:36:38 UTC+2 jrh...@gmail.com wrote:

> I was playing around with trying to use generics to de-interface-ify a 
> fuzzer implementation, and I ran into some stumbling blocks.
>
> is it possible to perform type switches? It seems the answer is currently 
> no (example , design doc 
> reference 
> ).
>  
> Maybe there's a better way to handle the following?
>
> type Primitive interface {
>   type int, string
> }
>
> func Randomize(type F Primitive)(f F, r *rand.Rand) F {
>   switch v := (interface{})(f).(type) {
>   case string:
> return fmt.Sprintf("%s--%d", v, r.Int())
>   case int:
> return v + r.Int()
>   default:
> panic(fmt.Sprintf("I don't know about type %T!\n", v))
>   }
> }
>
> func main() {
>   r := rand.New(rand.NewSource(1))
>   fmt.Println(Randomize(int)(1, r))
> }
>
> Thanks,
> Josh
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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/c4c0c308-bd05-48eb-aa60-bcbcc2932399n%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] [generics] Fuzzer, Type Switches

[Josh Hoak]

I was playing around with trying to use generics to de-interface-ify a
fuzzer implementation, and I ran into some stumbling blocks.

is it possible to perform type switches? It seems the answer is currently
no (example , design doc
reference
).
Maybe there's a better way to handle the following?

type Primitive interface {
  type int, string
}

func Randomize(type F Primitive)(f F, r *rand.Rand) F {
  switch v := (interface{})(f).(type) {
  case string:
return fmt.Sprintf("%s--%d", v, r.Int())
  case int:
return v + r.Int()
  default:
panic(fmt.Sprintf("I don't know about type %T!\n", v))
  }
}

func main() {
  r := rand.New(rand.NewSource(1))
  fmt.Println(Randomize(int)(1, r))
}

Thanks,
Josh

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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/CAJoEjeXcjS1xBhsPM_CLA_zBwS-e0WdA%3D4ngQnRz6daReXeR7g%40mail.gmail.com.

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

[Ian Lance Taylor]

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

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

Ian

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

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

[Ian Lance Taylor]

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

Re: [go-nuts] Re: Considering dropping GO386=387

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 12:54 AM Hunter Herman  wrote:
>
> Hi Austin! I’m very curious about the register based calling convention you 
> referenced in your email. Could you share more (informal is fine) details?

See https://golang.org/issue/18597 and https://golang.org/issue/27539.

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/CAOyqgcXbThDmg2GHPy1pmr3wu-_SLixq-w5jDfja7oMvKTYKPg%40mail.gmail.com.

Re: [go-nuts] is golang(1.13)'s parser is a LL(1) parser?

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 8:28 AM xie cui  wrote:
>
> is golang(1.13)'s parser is a LL(1) parser?

The parser used by the gc compiler is a recursive descent parser
(https://golang.org/src/cmd/compile/internal/syntax/parser.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/CAOyqgcX90E60Tmbq%2B58yb72xacUqj65Wb4YjOUFykutO5twHeg%40mail.gmail.com.

Re: [go-nuts] is golang(1.13)'s parser is a LL(1) parser?

[Jan Mercl]

Go grammar is not LL(1) AFAICT. It's very close to LALR(1), but with an
ambiguity that has a fully defined resolution in the language specification.


On Fri, Jul 17, 2020, 17:28 xie cui  wrote:

> is golang(1.13)'s parser is a LL(1) 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/e76ff1b7-926f-4859-b358-2aa20df562ffn%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/CAA40n-WyPtHppbdWKJHebfUHWOno8zu5BqCcPstkFNnGA%3DtReQ%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

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/CAOyqgcXterzGR2QekJjQaVX-RNYaraQrW35eXm-tiz%3D4z2JoqQ%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Fri, Jul 17, 2020 at 5:40 AM giuliom...@gmail.com
 wrote:
>
> I believe this is an important part of the community, without such process, 
> we would not get new smart ideas for Go. I don't know exactly the rejection 
> rate, but even if it was 1 accepted idea out of 100, all of them must be 
> reviewed in order to spot the right one.
>
> On the other hand, I understand your point and the reason why the review 
> approach has changed. I personally think it makes perfectly sense.
>
> However, how can we make sure that we don't miss smart ideas for Go 2? I 
> guess that someone must still to spend their time in reviewing and selecting.

We'll still read all the proposals.

Ian


> On Friday, July 17, 2020 at 12:36:37 AM UTC+2 Ian Lance Taylor wrote:
>>
>> 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?
>>
>>
>> I think one way to describe what is happening is our growing awareness
>> over time that most language change proposals don't bring enough
>> value. 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. What has been happening with
>> language change proposals is that we say we don't see enough value,
>> but naturally the proposer does see value, and often is not happy
>> about our comments. Then we get into an uncomfortable discussion
>> where we say no and the proposer says why not. This leads to hurt
>> feelings and no useful progress, and we certainly don't feel good
>> about it ourselves. For example, just to pick on one perhaps
>> unfairly, see https://golang.org/issue/39530.
>>
>> I agree that feedback should ideally help to refine future requests,
>> but after a couple of years of feedback I see no evidence that that is
>> happening. Maybe our feedback is bad, but I also suspect that part of
>> the problem is that most people who want to suggest a language change
>> don't read the earlier feedback. Or perhaps the ones who do just
>> don't go on to propose a change after all. I can certainly understand
>> not reading all the feedback; there are 89 issues just on the topic of
>> error handling alone, some of them quite long. But it follows that I
>> can understand that the feedback isn't helping much.
>>
>> This doesn't mean that there will be some other process for making
>> language changes. It's still the same process. There is no special
>> route for Google employees (and most proposals by Google employees are
>> rejected, just like most proposals by non-Google-employees). What it
>> means, I hope, is that more changes will be rejected more quickly and
>> with less back and forth discussion.
>>
>> One observation that led to this change is that often we would look at
>> a proposal and immediately say "well, this one is not going to be
>> accepted." But then it would take us 30 minutes to explain why, and
>> then we would spend another few hours over the next few weeks replying
>> to comments. But the fact was we knew in 30 seconds that it wasn't
>> going to be accepted. It may sound blunt, but I think it will be a
>> net benefit to the overall ecosystem to spend just 1 minute on that
>> kind of proposal, not several hours over time.
>>
>> Hope this helps. Happy to hear comments.
>>
>> 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 

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

[Nathan Bosscher]

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

Looking forward to getting generics in Go!

Nate

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

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

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

Re: [go-nuts] Go 2 review process

[medienwer...@gmail.com]

Dear Ian

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 

 
giuliom...@gmail.com schrieb am Freitag, 17. Juli 2020 um 14:39:55 UTC+2:

>
> I believe this is an important part of the community, without such 
> process, we would not get new smart ideas for Go. I don't know exactly the 
> rejection rate, but even if it was 1 accepted idea out of 100, all of them 
> must be reviewed in order to spot the right one. 
>
> On the other hand, I understand your point and the reason why the review 
> approach has changed. I personally think it makes perfectly sense.
>
> However, how can we make sure that we don't miss smart ideas for Go 2? I 
> guess that someone must still to spend their time in reviewing and 
> selecting.
>
> Thanks
> Giulio
>
> On Friday, July 17, 2020 at 12:36:37 AM UTC+2 Ian Lance Taylor wrote:
>
>> 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? 
>>
>>
>> I think one way to describe what is happening is our growing awareness 
>> over time that most language change proposals don't bring enough 
>> value. 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. What has been happening with 
>> language change proposals is that we say we don't see enough value, 
>> but naturally the proposer does see value, and often is not happy 
>> about our comments. Then we get into an uncomfortable discussion 
>> where we say no and the proposer says why not. This leads to hurt 
>> feelings and no useful progress, and we certainly don't feel good 
>> about it ourselves. For example, just to pick on one perhaps 
>> unfairly, see https://golang.org/issue/39530. 
>>
>> I agree that feedback should ideally help to refine future requests, 
>> but after a couple of years of feedback I see no evidence that that is 
>> happening. Maybe our feedback is bad, but I also suspect that part of 
>> the problem is that most people who want to suggest a language change 
>> don't read the earlier feedback. Or perhaps the ones who do just 
>> don't go on to propose a change after all. I can certainly understand 
>> not reading all the feedback; there are 89 issues just on the topic of 
>> error handling alone, some of them quite long. But it follows that I 
>> can understand that the feedback isn't helping much. 
>>
>> This doesn't mean that there will be some other process for making 
>> language changes. It's still the same process. There is no special 
>> route for Google employees (and most proposals by Google employees are 
>> rejected, just like most proposals by non-Google-employees). What it 
>> means, I hope, is that more changes will be rejected more quickly and 
>> with less back and forth discussion. 
>>
>> One observation that led to this change is that often we would look at 
>> a proposal and immediately say "well, this one is not going to be 
>> accepted." But then it would take us 30 minutes to explain why, and 
>> then we would spend another few hours over the next few weeks replying 
>> to comments. But the fact was 

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

[Michael Jones]

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

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

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


-- 

*Michael T. jonesmichael.jo...@gmail.com *

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

Re: [go-nuts] where is temp file created by http server

[Jake Montgomery]

On Thursday, July 16, 2020 at 10:32:32 PM UTC-4, hao dong wrote:
>
> thanks. I've noticed the code,too. And that's what I'm confused: when 
> there is a create, there is no delete, and I can not find the file under 
> os.TemDir()
> Seems I have to debug the code to find the removing line.
>

I believe the delete happens at the end of finishRequest: 
https://golang.org/src/net/http/server.go#L1612

if w.req.MultipartForm != nil {

 w.req.MultipartForm.RemoveAll()

}


Not verified, but that looks like 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/92207273-e6e2-4f31-81bd-691ffe7c7c25o%40googlegroups.com.

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

[Jon Conradt]

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

Jon

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

> On Tue, Jul 14, 2020 at 7:45 PM Watson Ladd  wrote:
> >
> > Guillamets are worth consideration. They are common on European 
> keyboards and avoid all the syntax ambiguities.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-use
>
> Ian
>

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

[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] url to download go package?

[rohitpotter12]

Hi,
We can download gem package by 
https://rubygems.org/downloads/{name}-{version}.gem, cargo creates by 
https://crates.io/api/v1/crates/{name}/{version}/download. We can download 
download package directly by this url.


Is there any url to download the go package directly from it if we don't 
have the version number??

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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/a6c7029f-9cc7-4dd3-9480-ffa33a318840o%40googlegroups.com.

[go-nuts] is golang(1.13)'s parser is a LL(1) parser?

[xie cui]

is golang(1.13)'s parser is a LL(1) 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/e76ff1b7-926f-4859-b358-2aa20df562ffn%40googlegroups.com.

Re: [go-nuts] Go 2 review process

[giuliom...@gmail.com]

I believe this is an important part of the community, without such process, 
we would not get new smart ideas for Go. I don't know exactly the rejection 
rate, but even if it was 1 accepted idea out of 100, all of them must be 
reviewed in order to spot the right one. 

On the other hand, I understand your point and the reason why the review 
approach has changed. I personally think it makes perfectly sense.

However, how can we make sure that we don't miss smart ideas for Go 2? I 
guess that someone must still to spend their time in reviewing and 
selecting.

Thanks
Giulio

On Friday, July 17, 2020 at 12:36:37 AM UTC+2 Ian Lance Taylor wrote:

> 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?
>
>
> I think one way to describe what is happening is our growing awareness
> over time that most language change proposals don't bring enough
> value. 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. What has been happening with
> language change proposals is that we say we don't see enough value,
> but naturally the proposer does see value, and often is not happy
> about our comments. Then we get into an uncomfortable discussion
> where we say no and the proposer says why not. This leads to hurt
> feelings and no useful progress, and we certainly don't feel good
> about it ourselves. For example, just to pick on one perhaps
> unfairly, see https://golang.org/issue/39530.
>
> I agree that feedback should ideally help to refine future requests,
> but after a couple of years of feedback I see no evidence that that is
> happening. Maybe our feedback is bad, but I also suspect that part of
> the problem is that most people who want to suggest a language change
> don't read the earlier feedback. Or perhaps the ones who do just
> don't go on to propose a change after all. I can certainly understand
> not reading all the feedback; there are 89 issues just on the topic of
> error handling alone, some of them quite long. But it follows that I
> can understand that the feedback isn't helping much.
>
> This doesn't mean that there will be some other process for making
> language changes. It's still the same process. There is no special
> route for Google employees (and most proposals by Google employees are
> rejected, just like most proposals by non-Google-employees). What it
> means, I hope, is that more changes will be rejected more quickly and
> with less back and forth discussion.
>
> One observation that led to this change is that often we would look at
> a proposal and immediately say "well, this one is not going to be
> accepted." But then it would take us 30 minutes to explain why, and
> then we would spend another few hours over the next few weeks replying
> to comments. But the fact was we knew in 30 seconds that it wasn't
> going to be accepted. It may sound blunt, but I think it will be a
> net benefit to the overall ecosystem to spend just 1 minute on that
> kind of proposal, not several hours over time.
>
> Hope this helps. Happy to hear comments.
>
> 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/61a2e91a-8505-4a45-976f-3813d59ca746n%40googlegroups.com.

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

[Ian Davis]

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/83d2930f-347d-41a0-b8cd-f0b51ba22e5a%40www.fastmail.com.

Re: [go-nuts] compress/flate

[Jan Mercl]

On Fri, Jul 17, 2020 at 11:23 AM Heisenberg  wrote:
>
> Constant definition in token.go:
>
> literalType = 0 << 30
>
> The only use I see is:
>
> func (t token) literal() uint32 { return uint32(t - literalType) }
> func literalToken(literal uint32) token { return token(literalType + literal) 
> }
>
>
> I don't know what the purpose of this writing is. Is it okay to remove 
> literalType?

No, it's a particular value of  bitfield. That the value happens to be
zero does not matter. Written this way it's future-proof - would the
value need change to some other value.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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-Wg7%3DYBo6pkVWxEmfCq4VNzeydDUUZA%2BQN2cHEU6ohJuw%40mail.gmail.com.

[go-nuts] compress/flate

[Heisenberg]

Constant definition in token.go:

literalType = 0 << 30

The only use I see is:


   - *func (t token) literal() uint32 { return uint32(t - literalType) }*
   - 
*func literalToken(literal uint32) token { return token(literalType + 
   literal) } *


I don't know what the purpose of this writing is. Is it okay to remove 
literalType?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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/af013b97-cbdb-4324-9f65-2af1e9d4e9den%40googlegroups.com.

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

[Markus Heukelom]

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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/245ce96d-52e4-4763-9296-58b8fdf26b1bn%40googlegroups.com.

Re: [go-nuts] Re: Considering dropping GO386=387

[Hunter Herman]

Hi Austin! I’m very curious about the register based calling convention you 
referenced in your email. Could you share more (informal is fine) details?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To 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/8591e7ec-1418-4ac7-834d-93d1a00eb540o%40googlegroups.com.