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

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

[go-nuts] Re: Generics and parentheses

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

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

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

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

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

[go-nuts] Pointers to allocated memory objects?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[go-nuts] Re: Generics and parentheses

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 >

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

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

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

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

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

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 >

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

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

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

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

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

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

Re: [go-nuts] Go 2 review process

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

Re: [go-nuts] Go 2 review process

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 >

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

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.

Re: [go-nuts] Go 2 review process

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

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

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

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

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

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

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

[go-nuts] Re: Generics and parentheses

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?

[go-nuts] url to download go package?

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

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

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

Re: [go-nuts] Go 2 review process

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

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

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

Re: [go-nuts] compress/flate

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

[go-nuts] compress/flate

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

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

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

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

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