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

[Kevin Gillette]

On Wednesday, July 15, 2020 at 6:41:51 AM UTC-6 Michal Strba wrote:

> What about using a dot when specializing in bodies?
>
> func main() {
> x := zero.() // requires a dot
> }
>

What are all the kinds of "generic expressions" we would need to support? 
Go allows incomplete floating point literals (such as `x := 3.`)... Could 
angle brackets ever appear on the right side of such a floating point 
literal to mean something generic? If so, it would be ambiguous with a 
less-than comparison.

-- 
You received this message because you are subscribed to the Google 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/c94e7926-47c8-4530-9b37-70066a1be72dn%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Bit0r Mack]

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

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

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

Re: [go-nuts] what is walk(fn *Node) for?

[Keith Randall]

In addition to what Jesper said, the walk pass does a variety of lowerings 
and optimizations on the ast. For example, it rewrites the builtin `new` to 
a runtime call, rewrites switches to a tree of `if` statements, etc.

On Monday, July 20, 2020 at 2:11:08 AM UTC-7 jesper.lou...@gmail.com wrote:

> From a quick glance that might be wrong:
>
> It looks like the walk function visits an abstract syntax tree (AST) and 
> performs checks for the statics part of the compiler. E.g., it finds unused 
> variables and functions, type-illegal statements and so on. The term "walk" 
> is used as in that it "walks over the tree and visits each node". The 
> purpose is likely to set up the AST in a state where it is well-typed. This 
> simplifies later stages of the compiler as it can assume certain 
> well-formed principles of the AST structure.
>
> On Mon, Jul 20, 2020 at 4:39 AM xie cui  wrote:
>
>> the go tool compile will call walk, what 's effect of this call?
>>
>> https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/walk.go#L20
>>
>> -- 
>> You received this message because you are subscribed 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/6a65acad-3756-4d77-bf16-23be1a1f9055n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> J.
>

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

Re: [go-nuts] Proposal for compile-time package overrides support

[Yuriy Yarosh]

> https://golang.org/issue/35283

Yup, thanks for pointing this out.

On Tuesday, July 21, 2020 at 12:09:07 AM UTC+3 Ian Lance Taylor wrote:

> On Mon, Jul 20, 2020 at 12:48 PM Yuriy Yarosh  wrote:
> >
> > > don't think it's going to be feasible to make it possible to
> > replace the standard library net package.
> >
> > Well, I'm not proposing to replace entirely, just to add some 
> annotations for the compiler, like use this instead of net package over 
> here...
>
> Yes, that is also what I meant. Replace in the sense of "replace at
> compile time."
>
>
> > > That's a lot of work and a
> > massive increase in required testing configurations
> >
> > Well, not really... it's application specific and could provide real 
> highload capabilities for golang i.e. 300K-1M RPS per node because of 
> Kernel bypass.
> > Reducing clusters from 32 machines to 4 is not a minimal gain, ofc it 
> should be completely optional.
>
> I'm sorry, I don't understand how your comment addresses my objection.
>
> See https://golang.org/issue/35283.
>
> Ian
>
>
>
> > On Monday, July 20, 2020 at 10:30:20 PM UTC+3 Ian Lance Taylor wrote:
> >>
> >> On Mon, Jul 20, 2020 at 12:23 PM Yuriy Yarosh  
> wrote:
> >> >
> >> > Basically I'm replacing net package partially rn with custom 
> DPDK-enabled impl right now i.e. everything syscall.Socket related.
> >> > It's not about the protocols, it's about replacing whole BSD sock API 
> and epoll/kqueue with a custom impl enterily.
> >> > I've managed to impl a PoC for this, might create a golang PR 
> soon(-ish) after getting some opinions.
> >> > Dubbed at slack #dartarts.
> >>
> >> I see. I don't think it's going to be feasible to make it possible to
> >> replace the standard library net package. That's a lot of work and a
> >> massive increase in required testing configurations for relatively
> >> minimal gain.
> >>
> >> Since you mentioned JSON I'll note that the encoding/json package does
> >> not depend on the net package.
> >>
> >> Ian
> >>
> >>
> >> > On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote:
> >> >>
> >> >> On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh  
> wrote:
> >> >> >
> >> >> > Basically I've got some different tcp/ip stack implementations 
> based on DPDK and want to be able to replace existing types and methods of 
> the stock net package, which would allow to add DPDK support for existing 
> apps without any amends as a complete plug'n'play.
> >> >> > Same goes for JSON serialization and similar non-optimized 
> implementations.
> >> >> >
> >> >> > Stdlib shouldn't be perfect, but developers should be able to use 
> optimized implementations as a drop-in replacement when necessary.
> >> >> >
> >> >> > What do you think guys ?
> >> >>
> >> >> I'm not sure quite what you are suggesting. But the net package does
> >> >> intend to support alternate protocols via calls like syscall.Socket
> >> >> followed by os.NewFile and net.FileConn.
> >> >>
> >> >> 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/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/d3e42b12-3177-4dc7-8522-d3058ab1f9c4n%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/839abe73-ec72-4141-a9ea-d75eb1e8fa08n%40googlegroups.com.

Re: [go-nuts] Proposal for compile-time package overrides support

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 12:48 PM Yuriy Yarosh  wrote:
>
> >  don't think it's going to be feasible to make it possible to
> replace the standard library net package.
>
> Well, I'm not proposing to replace entirely, just to add some annotations for 
> the compiler, like use this instead of net package over here...

Yes, that is also what I meant.  Replace in the sense of "replace at
compile time."


> > That's a lot of work and a
> massive increase in required testing configurations
>
> Well, not really... it's application specific and could provide real highload 
> capabilities for golang i.e. 300K-1M RPS per node because of Kernel bypass.
> Reducing clusters from 32 machines to 4 is not a minimal gain, ofc it should 
> be completely optional.

I'm sorry, I don't understand how your comment addresses my objection.

See https://golang.org/issue/35283.

Ian



> On Monday, July 20, 2020 at 10:30:20 PM UTC+3 Ian Lance Taylor wrote:
>>
>> On Mon, Jul 20, 2020 at 12:23 PM Yuriy Yarosh  wrote:
>> >
>> > Basically I'm replacing net package partially rn with custom DPDK-enabled 
>> > impl right now i.e. everything syscall.Socket related.
>> > It's not about the protocols, it's about replacing whole BSD sock API and 
>> > epoll/kqueue with a custom impl enterily.
>> > I've managed to impl a PoC for this, might create a golang PR soon(-ish) 
>> > after getting some opinions.
>> > Dubbed at slack #dartarts.
>>
>> I see. I don't think it's going to be feasible to make it possible to
>> replace the standard library net package. That's a lot of work and a
>> massive increase in required testing configurations for relatively
>> minimal gain.
>>
>> Since you mentioned JSON I'll note that the encoding/json package does
>> not depend on the net package.
>>
>> Ian
>>
>>
>> > On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote:
>> >>
>> >> On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh  wrote:
>> >> >
>> >> > Basically I've got some different tcp/ip stack implementations based on 
>> >> > DPDK and want to be able to replace existing types and methods of the 
>> >> > stock net package, which would allow to add DPDK support for existing 
>> >> > apps without any amends as a complete plug'n'play.
>> >> > Same goes for JSON serialization and similar non-optimized 
>> >> > implementations.
>> >> >
>> >> > Stdlib shouldn't be perfect, but developers should be able to use 
>> >> > optimized implementations as a drop-in replacement when necessary.
>> >> >
>> >> > What do you think guys ?
>> >>
>> >> I'm not sure quite what you are suggesting. But the net package does
>> >> intend to support alternate protocols via calls like syscall.Socket
>> >> followed by os.NewFile and net.FileConn.
>> >>
>> >> 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/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%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/d3e42b12-3177-4dc7-8522-d3058ab1f9c4n%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/CAOyqgcW74DtLJ0DzxkN5gZDTbCdyyq0V5hXkn%2BA-K-OR2dqwXA%40mail.gmail.com.

Re: [go-nuts] How CGO create _Ctype_char and other default C types? I can not build my program on machine with char being unsigned by default

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 1:40 PM Mahdi Hosseini  wrote:
>
> Thanks that was a valuable information. It might be the debugging flag that 
> caused the issue. I debugged the cgo file and found that in char* mached with 
> dwarf.UcharType instead of dwarf.chatType

I think that that in itself shouldn't matter, the question is what is
the DW_AT_name attribute of the unsigned character type.

Ian

> On Monday, July 20, 2020 at 3:45:00 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Mon, Jul 20, 2020 at 12:28 PM Mahdi Hosseini  wrote:
>> >
>> > Hi,
>> > I try to recompile Go for a new platform which is a s390x platform using 
>> > Clang instead of GCC. I can not work for C string in CGO. Apparently char 
>> > in unsigned by default on my platform and building even the simple CGO 
>> > program always fails with this error:
>> >
>> > /home/user/tmp/go-build468743286/b001/_cgo_gotypes.go:175:25: undefined: 
>> > _Ctype_char
>> >
>> > the code is:
>> >
>> > package main
>> >
>> > //#include 
>> > //char* callC() {
>> > // return "Calling C code!";
>> > //}
>> > import "C"
>> >
>> > import "fmt"
>> >
>> > func main() {
>> > fmt.Println("Convert C String to Go String")
>> > str := C.GoString(C.callC())
>> > fmt.Println(str)
>> > }
>> >
>> > to overcome this I modified the gcc.go file in src/cmd/cgo and added this:
>> >
>> > if s == "uchar" {
>> > s = "char"
>> > }
>> > name := c.Ident("_Ctype_" + s)
>> > I don't now how CGO always convert my char* to *_Ctype_uchar instead of 
>> > *_Ctype_char.
>> > Anyone have a clue on this?
>>
>> cgo is just using the debug information generated by the C compiler.
>> It expects to see debug info for the type "char".  For example, if I
>> compile this C file
>>
>> #include 
>> char* callC() {
>>  return "Calling C code!";
>> }
>>
>> with clang on my system and run "readelf --debug" on the resulting
>> object file, I see
>>
>>  <1><48>: Abbrev Number: 4 (DW_TAG_base_type)
>> <49>   DW_AT_name: (indirect string, offset: 0x4c): char
>> <4d>   DW_AT_encoding: 6(signed char)
>> <4e>   DW_AT_byte_size   : 1
>>
>> cgo will use this to define the type "C.char".
>>
>> This is independent of whether char is signed or unsigned.  Given that
>> your code uses "char", it surprises me that there is no named entry
>> for it in the debug info.
>>
>> 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/f4a72340-018e-4172-b702-af4f03ad48f1o%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/CAOyqgcXYNDDuX5hhxyQfJwXg_Nvd3X4j8hduj8NJ6ZVnt1w4Cg%40mail.gmail.com.

[go-nuts] arm v8 SIMD

[Stefan Solbrig]

Hi all,

I was wondering if (or to what extend) gc supports generation of SIMD 
instructions on arm64.  Especially:  is it possible to set a compile time 
flag such that gc creates  NEON instructions only  or NEON and  especially 
SVE instructions?

best wishes,
Stefan

-- 
You received this message because you are subscribed to the Google 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/df6651df-b7d0-4b4f-b24b-14e5dbb0d60cn%40googlegroups.com.

Re: [go-nuts] How CGO create _Ctype_char and other default C types? I can not build my program on machine with char being unsigned by default

[Mahdi Hosseini]

Thanks that was a valuable information. It might be the debugging flag that 
caused the issue. I debugged the cgo file and found that in char* mached 
with dwarf.UcharType instead of dwarf.chatType

On Monday, July 20, 2020 at 3:45:00 PM UTC-4, Ian Lance Taylor wrote:
>
> On Mon, Jul 20, 2020 at 12:28 PM Mahdi Hosseini  > wrote: 
> > 
> > Hi, 
> > I try to recompile Go for a new platform which is a s390x platform using 
> Clang instead of GCC. I can not work for C string in CGO. Apparently char 
> in unsigned by default on my platform and building even the simple CGO 
> program always fails with this error: 
> > 
> > /home/user/tmp/go-build468743286/b001/_cgo_gotypes.go:175:25: undefined: 
> _Ctype_char 
> > 
> > the code is: 
> > 
> > package main 
> > 
> > //#include  
> > //char* callC() { 
> > // return "Calling C code!"; 
> > //} 
> > import "C" 
> > 
> > import "fmt" 
> > 
> > func main() { 
> > fmt.Println("Convert C String to Go String") 
> > str := C.GoString(C.callC()) 
> > fmt.Println(str) 
> > } 
> > 
> > to overcome this I modified the gcc.go file in src/cmd/cgo and added 
> this: 
> > 
> > if s == "uchar" { 
> > s = "char" 
> > } 
> > name := c.Ident("_Ctype_" + s) 
> > I don't now how CGO always convert my char* to *_Ctype_uchar instead of 
> *_Ctype_char. 
> > Anyone have a clue on this? 
>
> cgo is just using the debug information generated by the C compiler. 
> It expects to see debug info for the type "char".  For example, if I 
> compile this C file 
>
> #include  
> char* callC() { 
>  return "Calling C code!"; 
> } 
>
> with clang on my system and run "readelf --debug" on the resulting 
> object file, I see 
>
>  <1><48>: Abbrev Number: 4 (DW_TAG_base_type) 
> <49>   DW_AT_name: (indirect string, offset: 0x4c): char 
> <4d>   DW_AT_encoding: 6(signed char) 
> <4e>   DW_AT_byte_size   : 1 
>
> cgo will use this to define the type "C.char". 
>
> This is independent of whether char is signed or unsigned.  Given that 
> your code uses "char", it surprises me that there is no named entry 
> for it in the debug info. 
>
> 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/f4a72340-018e-4172-b702-af4f03ad48f1o%40googlegroups.com.

Re: [go-nuts] [generics] Type embedding in generic types

['Axel Wagner' via golang-nuts]

Hi,

given the discussion here, the blog post I just published might be
interesting:
https://blog.merovius.de/2020/07/20/parametric-context.html
To the best of my knowledge, what I describe there is only really doable
using embedded type-parameters. As I state in the conclusion, I'm not
entirely sure this would be something *good*. But I do think it adds more
type-safety and that does provide value.

Interested to hear your thoughts :)

Axel


On Mon, Jul 20, 2020 at 3:37 PM 'Javier Zunzunegui' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Coming back at this after more thought & exploration. The fundamental
> problem I see is it introduces complexity, but no value.
>
> Say
> `type I interface {...}`
> `type S(type T I) struct {T}`
> Then the generic S (before instantiating with a particular T) may
> implement any interface, e.g. in any method on S or any other generic code
> using S, you may have
> `_, ok := (interface{}(S(...){})` ).(Whatever)`
> and the result of ok depends on what T is used. Without embedding, that is
> strue of T but not S.
>
> # What value did this add?
> - You can call methods listed in I directly, e.g. if method Foo is in
> listed I, you can do s.Foo().
> => without embedding using s.I.Foo() is hardly a change.
> - You can implement interfaces based on method listed in I directly, e.g.
> if method Foo is listed in I and characterises interface Fooer, you can do
> Fooer(s).
> => without embedding, you can do Fooer(s.I) or if you actually want s
> in the interface, write a generic method Foo in S and keep Fooer(s).
> - You can implement interfaces based on method NOT listed in I directly,
> e.g. if method Foo is NOT listed in I, but is defined in some T and
> characterises interface Fooer, you can do Fooer(s) (for s := S(T){...}).
> => without embedding, you can't do this. You can do Fooer(s.I), or
> create a new type for this specificT,  `type X S(T)`, and implement method
> Foo, but let's assume that neither is acceptable. How realistic / in what
> circumstances do you want this? If you require a struct to have a method
> not listed in any contract but present in the type that happens to be
> embedded on this instance of the generic, and want it to be assigned to an
> interface that uses that method but won't accept either the embedded field
> in the interface, nor a separate type derived from it with the additional
> method, I'd say you need to re-evaluate your requirements because you are
> not following any moderatly sensible standards, or at the very least accept
> you are doing something wild and can't use generics for it.
>
> # What did this cost?
> - Complexity => the possibility of there being more methods available in a
> struct than listed in its definition is in itself one more thing to think
> about.
> - Refactoring => an embedding can't be refactored without a breacking
> change (can't change `type S(type T I) struct {T}` to `type S(type T I)
> struct {T}` + methods in I), since users may be relying on methods not
> present in I.
> - Limits to Tooling: without embedding, `_, ok := (interface{}(S(...){})`
> ).(Whatever)` above may always be false and the tooling may be able to
> identify and flag that, with embedding there is nothing it can do since it
> may always be true.
>
> # No arbitrary restrictions
> "our hope is to make generic types work as much like ordinary types as
> possible, without arbitrary restrictions"
> => this is indeed a restriction, and I don't know how much that
> weights in the go team's mind regarding future features, etc. But on the
> other hand even allowing embedding in generics isn't quite as pre-generics
> go either, after all you are embedding using the generic's type name (in my
> example, T) and not the name of the actuall type T is instantiated with. In
> other words, the type produced can't be replicated without generics.
> Banning embedding you limit slightly the types you can produce, but at
> least those that are allowed are valid pre-generic go types.
>
> And of course there is also a 'delay decision' argument here: if embedding
> is banned, it can be added later. If it is allowed, the decision is final.
>
> I do not claim anything dramatic about this feature's significance, like
> generics with fail if embedding is allowed, but also generics will not fail
> because they weren't. So if there is no strong reason for, and there are
> some reasons against, it seems to me the best decision is to ban at first
> and re-evaluate later.
> On Tuesday, July 14, 2020 at 11:41:42 AM UTC+2 Javier Zunzunegui wrote:
>
>> Issue openned in https://github.com/golang/go/issues/40199.
>>
>> Still clarifying my thoughts on embedding types within generics, will
>> postpone this debate while I focus on other parts of the proposal and gain
>> some more experience using the go2 branch. Not calling for any action here
>> at this point. Thanks Ian.
>> On Monday, July 13, 2020 at 7:03:35 PM UTC+2 Ian Lance Taylor wrote:
>>
>>> On 

Re: [go-nuts] Proposal for compile-time package overrides support

[Yuriy Yarosh]

>  don't think it's going to be feasible to make it possible to
replace the standard library net package. 

Well, I'm not proposing to replace entirely, just to add some annotations 
for the compiler, like use this instead of net package over here...

> That's a lot of work and a
massive increase in required testing configurations

Well, not really... it's application specific and could provide real 
highload capabilities for golang i.e. 300K-1M RPS per node because of 
Kernel bypass.
Reducing clusters from 32 machines to 4 is not a minimal gain, ofc it 
should be completely optional.
On Monday, July 20, 2020 at 10:30:20 PM UTC+3 Ian Lance Taylor wrote:

> On Mon, Jul 20, 2020 at 12:23 PM Yuriy Yarosh  wrote:
> >
> > Basically I'm replacing net package partially rn with custom 
> DPDK-enabled impl right now i.e. everything syscall.Socket related.
> > It's not about the protocols, it's about replacing whole BSD sock API 
> and epoll/kqueue with a custom impl enterily.
> > I've managed to impl a PoC for this, might create a golang PR soon(-ish) 
> after getting some opinions.
> > Dubbed at slack #dartarts.
>
> I see. I don't think it's going to be feasible to make it possible to
> replace the standard library net package. That's a lot of work and a
> massive increase in required testing configurations for relatively
> minimal gain.
>
> Since you mentioned JSON I'll note that the encoding/json package does
> not depend on the net package.
>
> Ian
>
>
> > On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote:
> >>
> >> On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh  
> wrote:
> >> >
> >> > Basically I've got some different tcp/ip stack implementations based 
> on DPDK and want to be able to replace existing types and methods of the 
> stock net package, which would allow to add DPDK support for existing apps 
> without any amends as a complete plug'n'play.
> >> > Same goes for JSON serialization and similar non-optimized 
> implementations.
> >> >
> >> > Stdlib shouldn't be perfect, but developers should be able to use 
> optimized implementations as a drop-in replacement when necessary.
> >> >
> >> > What do you think guys ?
> >>
> >> I'm not sure quite what you are suggesting. But the net package does
> >> intend to support alternate protocols via calls like syscall.Socket
> >> followed by os.NewFile and net.FileConn.
> >>
> >> 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/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%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/d3e42b12-3177-4dc7-8522-d3058ab1f9c4n%40googlegroups.com.

Re: [go-nuts] How CGO create _Ctype_char and other default C types? I can not build my program on machine with char being unsigned by default

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 12:28 PM Mahdi Hosseini  wrote:
>
> Hi,
> I try to recompile Go for a new platform which is a s390x platform using 
> Clang instead of GCC. I can not work for C string in CGO. Apparently char in 
> unsigned by default on my platform and building even the simple CGO program 
> always fails with this error:
>
> /home/user/tmp/go-build468743286/b001/_cgo_gotypes.go:175:25: undefined: 
> _Ctype_char
>
> the code is:
>
> package main
>
> //#include 
> //char* callC() {
> // return "Calling C code!";
> //}
> import "C"
>
> import "fmt"
>
> func main() {
> fmt.Println("Convert C String to Go String")
> str := C.GoString(C.callC())
> fmt.Println(str)
> }
>
> to overcome this I modified the gcc.go file in src/cmd/cgo and added this:
>
> if s == "uchar" {
> s = "char"
> }
> name := c.Ident("_Ctype_" + s)
> I don't now how CGO always convert my char* to *_Ctype_uchar instead of 
> *_Ctype_char.
> Anyone have a clue on this?

cgo is just using the debug information generated by the C compiler.
It expects to see debug info for the type "char".  For example, if I
compile this C file

#include 
char* callC() {
 return "Calling C code!";
}

with clang on my system and run "readelf --debug" on the resulting
object file, I see

 <1><48>: Abbrev Number: 4 (DW_TAG_base_type)
<49>   DW_AT_name: (indirect string, offset: 0x4c): char
<4d>   DW_AT_encoding: 6(signed char)
<4e>   DW_AT_byte_size   : 1

cgo will use this to define the type "C.char".

This is independent of whether char is signed or unsigned.  Given that
your code uses "char", it surprises me that there is no named entry
for it in the debug info.

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/CAOyqgcW495hYL-yjFB2dAx7z_A_HwEin9-nQKRG18-wvcKXgCg%40mail.gmail.com.

[go-nuts] module questions

['K Richard Pixley' via golang-nuts]

I'm think I understand the go-1.14 downloadable module workflow. But I'm 
not getting how to use modules in an enterprise system where we cannot 
allow automated downloads or where I want to include packages from one 
local module in another where neither are available on any public 
download server.


Are there instructions or discussion of the enterprise workflow 
available anywhere?


--
You received this message because you are subscribed to the Google 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/469be58a-6586-d1c0-6e42-eabfc1c9fbfc%40juniper.net.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 12:26 PM Geoff Speicher  wrote:
>
> On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor  wrote:
>>
>> On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher  wrote:
>> >
>> > This is great work but compared to the rest of Go's existing syntax, I 
>> > personally find it much harder to grok the generic code examples 
>> > regardless of bracket choice.
>> >
>> > It seems like a lot of complication stems from what effectively amounts to 
>> > requiring the programmer to declare a new generic type everyplace one is 
>> > needed. This seems like a lot of unnecessary noise, especially when you 
>> > consider that a package is likely to reuse generic types.
>> > [clip]
>>
>> This seems similar to the discussion at
>> https://groups.google.com/d/msg/golang-nuts/mXn9x01mFzM/Zf7lSXVuBgAJ .
>>
>> It seems hard to know how to instantiate a generic function or type,
>> as there is no clear information in the declaration as to the presence
>> or order of the type parameters.
>
>
> I see. Is the problem here theoretically limited to the scenarios where type 
> inference does not work in the current design?

Yes, the problem I mentioned only arises in cases where type inference fails.

Ian

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

Re: [go-nuts] Proposal for compile-time package overrides support

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 12:23 PM Yuriy Yarosh  wrote:
>
> Basically I'm replacing net package partially rn with custom DPDK-enabled 
> impl right now i.e. everything syscall.Socket related.
> It's not about the protocols, it's about replacing whole BSD sock API and 
> epoll/kqueue with a custom impl enterily.
> I've managed to impl a PoC for this, might create a golang PR soon(-ish) 
> after getting some opinions.
> Dubbed at slack #dartarts.

I see.  I don't think it's going to be feasible to make it possible to
replace the standard library net package.  That's a lot of work and a
massive increase in required testing configurations for relatively
minimal gain.

Since you mentioned JSON I'll note that the encoding/json package does
not depend on the net package.

Ian


> On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote:
>>
>> On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh  wrote:
>> >
>> > Basically I've got some different tcp/ip stack implementations based on 
>> > DPDK and want to be able to replace existing types and methods of the 
>> > stock net package, which would allow to add DPDK support for existing apps 
>> > without any amends as a complete plug'n'play.
>> > Same goes for JSON serialization and similar non-optimized implementations.
>> >
>> > Stdlib shouldn't be perfect, but developers should be able to use 
>> > optimized implementations as a drop-in replacement when necessary.
>> >
>> > What do you think guys ?
>>
>> I'm not sure quite what you are suggesting. But the net package does
>> intend to support alternate protocols via calls like syscall.Socket
>> followed by os.NewFile and net.FileConn.
>>
>> 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/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%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/CAOyqgcXfmn-91PZ9OGascZisMa-V0T29Z_BNo4TwHrwi0-PWoQ%40mail.gmail.com.

[go-nuts] How CGO create _Ctype_char and other default C types? I can not build my program on machine with char being unsigned by default

[Mahdi Hosseini]

Hi,
I try to recompile Go for a new platform which is a s390x platform using 
Clang instead of GCC. I can not work for C string in CGO. Apparently char 
in unsigned by default on my platform and building even the simple CGO 
program always fails with this error:

*/home/user/tmp/go-build468743286/b001/_cgo_gotypes.go:175:25: undefined: 
_Ctype_char*

the code is:

package main

//#include 
//char* callC() {
// return "Calling C code!";
//}
import "C"

import "fmt"

func main() {
fmt.Println("Convert C String to Go String")
str := C.GoString(C.callC())
fmt.Println(str)
}

to overcome this I modified the gcc.go file in src/cmd/cgo and added this:

if s == "uchar" {
s = "char"
}
name := c.Ident("_Ctype_" + s)
I don't now how CGO always convert my char* to *_Ctype_uchar instead of 
*_Ctype_char.
Anyone have a clue on this?


-- 
You received this message because you are subscribed to the Google 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/5fdcd5ec-7589-46bf-b20e-b27a8002dd30o%40googlegroups.com.

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

[Geoff Speicher]

On Mon, Jul 20, 2020 at 2:04 PM Ian Lance Taylor  wrote:

> On Mon, Jul 20, 2020 at 9:42 AM Geoff Speicher  wrote:
> >
> > This is great work but compared to the rest of Go's existing syntax, I
> personally find it much harder to grok the generic code examples regardless
> of bracket choice.
> >
> > It seems like a lot of complication stems from what effectively amounts
> to requiring the programmer to declare a new generic type everyplace one is
> needed. This seems like a lot of unnecessary noise, especially when you
> consider that a package is likely to reuse generic types.
> > [clip]
>
> This seems similar to the discussion at
> https://groups.google.com/d/msg/golang-nuts/mXn9x01mFzM/Zf7lSXVuBgAJ .
>
> It seems hard to know how to instantiate a generic function or type,
> as there is no clear information in the declaration as to the presence
> or order of the type parameters.
>

I see. Is the problem here theoretically limited to the scenarios where
type inference does not work in the current design?

-- 
You received this message because you are subscribed to the Google 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/CAG0mjcnL1itH7o14KkdMY0fpQTzZzOpEomfxGAw-Q55phpd9HQ%40mail.gmail.com.

Re: [go-nuts] Proposal for compile-time package overrides support

[Yuriy Yarosh]

Basically I'm replacing net package partially rn with custom DPDK-enabled 
impl right now i.e. everything syscall.Socket related. 
It's not about the protocols, it's about replacing whole BSD sock API and 
epoll/kqueue with a custom impl enterily.
I've managed to impl a PoC for this, might create a golang PR soon(-ish) 
after getting some opinions.
Dubbed at slack #dartarts.
On Monday, July 20, 2020 at 9:38:26 PM UTC+3 Ian Lance Taylor wrote:

> On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh  wrote:
> >
> > Basically I've got some different tcp/ip stack implementations based on 
> DPDK and want to be able to replace existing types and methods of the stock 
> net package, which would allow to add DPDK support for existing apps 
> without any amends as a complete plug'n'play.
> > Same goes for JSON serialization and similar non-optimized 
> implementations.
> >
> > Stdlib shouldn't be perfect, but developers should be able to use 
> optimized implementations as a drop-in replacement when necessary.
> >
> > What do you think guys ?
>
> I'm not sure quite what you are suggesting. But the net package does
> intend to support alternate protocols via calls like syscall.Socket
> followed by os.NewFile and net.FileConn.
>
> 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/c37ffcc3-d787-446d-9812-bdfc25a3ac8en%40googlegroups.com.

Re: [go-nuts] [gollvm] Sanitizers

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 12:06 PM Guido Chari  wrote:
>
> I am trying to compile a go program with santizers using gollvm and I can not 
> workaround it. Is that possible?

As far as I know nobody has tried to make the various sanitizers work
with GoLLVM.  It's probably possible, but I would expect it to require
adding some additional information to the sanitizer libraries and/or
the GoLLVM frontend.

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

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

[yangw...@gmail.com]

No problem, i'm just curious.

Thanks.

mai

在2020年7月21日星期二 UTC+8 上午2:42:58 写道：

> On Mon, Jul 20, 2020 at 11:29 AM yangw...@gmail.com
>  wrote:
> >
> > The size of the archived go distributions is growing in newer go release.
> >
> > My question:
> > What are the main contents of these additions? Can the size of the 
> archived go distributions be reduced?
>
> The Go 1 compatibility guarantee (https://golang.org/doc/go1compat)
> pretty much guarantees that every new release will be larger. It's
> hard for us to get rid of existing code.
>
> Although the size is increasing the increase does not seem all that
> big, and the file size doesn't seem particularly large by modern
> standards. Is this causing a problem somewhere?
>
> Thanks.
>
> Ian
>
>
> > 在2020年7月21日星期二 UTC+8 上午2:16:19 写道：
> >>
> >> On Mon, Jul 20, 2020 at 10:41 AM yangw...@gmail.com
> >>  wrote:
> >> >
> >> > Yes, I'm asking about the size of the archived go distributions.
> >>
> >> Thanks. Now that we understand that, what is your question?
> >>
> >> Ian
> >>
> >>
> >> > 在2020年7月19日星期日 UTC+8 上午12:11:02 写道：
> >> >>
> >> >> 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...@googlegroups.com.
> >> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/874a0d0d-324e-46d1-9c2c-a119889fd00an%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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/3f99ea3b-58ae-4916-926f-32b20b161615n%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/e85ec02e-b438-4338-b172-49714441n%40googlegroups.com.

[go-nuts] [gollvm] Sanitizers

[Guido Chari]

Hi,

I am trying to compile a go program with santizers using gollvm and I can 
not workaround it. Is that possible?

Cheers,
Guido.

-- 
You received this message because you are subscribed to the Google 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/414b775b-bb27-430a-b69a-00fd16587ff7o%40googlegroups.com.

Re: [go-nuts] Allocating lots (e.g. a million) objects on the heap

[Robert Engels]

All you are doing is replicating manual memory management. If you are going to 
do that just use CGo with malloc & free so you will have decent debugging. 

If not, don’t do this at all and let the GC do its work (but Go lack of a 
generational GC might be an issue here). 

> On Jul 20, 2020, at 12:47 PM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> 
> Check https://godoc.org/modernc.org/memory, maybe it can be used in this 
> scenario. Note, using the package concurrently from multiple goroutines 
> requires coordination, like with a mutex.
> 
>> On Mon, Jul 20, 2020, 19:35  wrote:
>> I have an application where I will be allocating millions of data 
>> structures, all of the same size. My program will need to run continuously 
>> and be pretty responsive to 
>> its network peers.
>> 
>> The data is fairly static, once allocated it will rarely need to be modified 
>> or deleted.
>> 
>> In order to minimize the garbage collection scanning overhead, I was 
>> thinking of allocating large blocks on the heap that were a fixed size that 
>> would hold 20K or so elements
>> and then write a simple allocator to hand out pieces of those blocks when 
>> needed. Instead of having to scan millions of items on the heap, the GC 
>> would only be scanning 100 or so
>> items.
>> 
>> Sound reasonable?  Or does this 'go' against the golang way of doing things?
>> 
>> F
>> -- 
>> You received this message because you are subscribed to the Google 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/0be7d132-71d6-4ff9-a8eb-ca09a94fafeao%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-Vn%2Bg8Yb9%3DX-K_95%3Dt6kQ3gr43kpj9JMwxRk3FMEv00Rw%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/29FD40F9-DB62-4486-837C-70F0A9BD0BA1%40ix.netcom.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 11:29 AM yangw...@gmail.com
 wrote:
>
> The size of the archived go distributions is growing in newer go release.
>
> My question:
> What are the main contents of these additions? Can the size of the archived 
> go distributions be reduced?

The Go 1 compatibility guarantee (https://golang.org/doc/go1compat)
pretty much guarantees that every new release will be larger.  It's
hard for us to get rid of existing code.

Although the size is increasing the increase does not seem all that
big, and the file size doesn't seem particularly large by modern
standards.  Is this causing a problem somewhere?

Thanks.

Ian


> 在2020年7月21日星期二 UTC+8 上午2:16:19 写道：
>>
>> On Mon, Jul 20, 2020 at 10:41 AM yangw...@gmail.com
>>  wrote:
>> >
>> > Yes, I'm asking about the size of the archived go distributions.
>>
>> Thanks. Now that we understand that, what is your question?
>>
>> Ian
>>
>>
>> > 在2020年7月19日星期日 UTC+8 上午12:11:02 写道：
>> >>
>> >> 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...@googlegroups.com.
>> > To view this discussion on the web visit 
>> > https://groups.google.com/d/msgid/golang-nuts/874a0d0d-324e-46d1-9c2c-a119889fd00an%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/3f99ea3b-58ae-4916-926f-32b20b161615n%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/CAOyqgcVteiumGS_2Hn3gY5PhbyPAczcuLZ09kii1fTGJm7-Xrg%40mail.gmail.com.

Re: [go-nuts] Proposal for compile-time package overrides support

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 7:53 AM Yuriy Yarosh  wrote:
>
> Basically I've got some different tcp/ip stack implementations based on DPDK 
> and want to be able to replace existing types and methods of the stock net 
> package, which would allow to add DPDK support for existing apps without any 
> amends as a complete plug'n'play.
> Same goes for JSON serialization and similar non-optimized implementations.
>
> Stdlib shouldn't be perfect, but developers should be able to use optimized 
> implementations as a drop-in replacement when necessary.
>
> What do you think guys ?

I'm not sure quite what you are suggesting.  But the net package does
intend to support alternate protocols via calls like syscall.Socket
followed by os.NewFile and net.FileConn.

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

Re: [go-nuts] Gollvm failed to build hugo

[Ian Lance Taylor]

[ + thanm, cherryyz ]

On Mon, Jul 20, 2020 at 4:24 AM Yuan Ting  wrote:
>
> Hi, I try to build hugo with fresh gollvm but the linker complains that:
>
> # github.com/gohugoio/hugo
> /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
> split-stack sequence at section 1 offset 0
> /usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
> split-stack sequence at section 1 offset a6
>
> To reproduce:
>
> git clone https://github.com/gohugoio/hugo.git
> cd hugo && go build
>
> Platform: x86_64 ubuntu:20.04
> Gollvm build flags:
> cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 
> -DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G 
> Ninja
>
> --
> You received this message because you are subscribed to the Google 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/d722a1e8-d205-4c9e-8ae4-623c19dd2946o%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/CAOyqgcU-%2B_Of91weFM%3DB25%2B2-1auhi71a%2BA6EYDgu1dGoGOnaQ%40mail.gmail.com.

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

[yangw...@gmail.com]

The size of the archived go distributions is growing in newer go release.

My question:
What are the main contents of these additions? Can the size of the archived 
go distributions be reduced?

在2020年7月21日星期二 UTC+8 上午2:16:19 写道：

> On Mon, Jul 20, 2020 at 10:41 AM yangw...@gmail.com
>  wrote:
> >
> > Yes, I'm asking about the size of the archived go distributions.
>
> Thanks. Now that we understand that, what is your question?
>
> Ian
>
>
> > 在2020年7月19日星期日 UTC+8 上午12:11:02 写道：
> >>
> >> 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/874a0d0d-324e-46d1-9c2c-a119889fd00an%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/3f99ea3b-58ae-4916-926f-32b20b161615n%40googlegroups.com.

Re: [go-nuts] Go 2 review process

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 11:13 AM medienwer...@gmail.com
 wrote:
>
> re :  "However, I don't understand how to make
> that work in practice. "
>
> from my research so far I found tons of Github Actions related to 
> "Projects"...
>
> just some examples:
> https://github.com/marketplace/actions/all-in-one-project
> https://github.com/marketplace/actions/assign-to-one-project
> https://github.com/marketplace/actions/github-projects-column-mirror
> https://github.com/marketplace/actions/automate-projects
> ...
>
> My proposal:
>
> - you configure a public github project with columns ("proposal", "language 
> change", "Go2", "Feature Request",...) that operates on golang organizational 
> level; link it to go language repo!
> -  the contributer files a "request" issue(just title, feature, subject; no 
> details) in the go repo
> - @settings/users of the public project you invite the contributor to drop a 
> "proposal" note (maybe through github actions(?); this is the detailed 
> contribution, proposal!
> - in the project columns you make the "triage" by editing the note and/or 
> converting notes to issues ("RFCs") for tracking, label adding,...
>
> let me work on the github actions side in the next couple of days; maybe I 
> can figure out automation...

Thanks, but it's not the mechanical steps that are time consuming.

Ian



> Ian Lance Taylor schrieb am Freitag, 17. Juli 2020 um 19:54:46 UTC+2:
>>
>> 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/86ba57c2-7c82-4f0f-8a52-007c8ded6fd4n%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/CAOyqgcXEZiyW%3D0imRBAej0wf8E78j_dScOZLTOzj82WVX0%3DC6g%40mail.gmail.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 10:41 AM yangw...@gmail.com
 wrote:
>
> Yes, I'm asking about the size of the archived go distributions.

Thanks.  Now that we understand that, what is your question?

Ian


> 在2020年7月19日星期日 UTC+8 上午12:11:02 写道：
>>
>> 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/874a0d0d-324e-46d1-9c2c-a119889fd00an%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/CAOyqgcXaD9ztwhDpBQvitPk4CKSfrGStubtFA886%3D9zwG%2BfxAA%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[medienwer...@gmail.com]

Dear Ian

re :  "However, I don't understand how to make
that work in practice. " 

from my research so far I found tons of Github Actions related to 
"Projects"...

just some examples: 
https://github.com/marketplace/actions/all-in-one-project
https://github.com/marketplace/actions/assign-to-one-project
https://github.com/marketplace/actions/github-projects-column-mirror
https://github.com/marketplace/actions/automate-projects
...

My proposal:

- you configure a public github project with columns ("proposal", "language 
change", "Go2", "Feature Request",...) that operates on golang 
organizational level; link it to go language repo!
-  the contributer files a "request" issue(just title, feature, subject; no 
details) in the go repo
- @settings/users of the public project you invite the contributor to drop 
a "proposal" note (maybe through github actions(?); this is the detailed 
contribution, proposal!
- in the project columns you make the "triage" by editing the note and/or 
converting notes to issues ("RFCs") for tracking, label adding,...

let me work on the github actions side in the next couple of days; maybe I 
can figure out automation...

Regards

Matthias


Ian Lance Taylor schrieb am Freitag, 17. Juli 2020 um 19:54:46 UTC+2:

> 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/86ba57c2-7c82-4f0f-8a52-007c8ded6fd4n%40googlegroups.com.

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

[Ian Lance Taylor]

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


This seems similar to the discussion at
https://groups.google.com/d/msg/golang-nuts/mXn9x01mFzM/Zf7lSXVuBgAJ .

It seems hard to know how to instantiate a generic function or type,
as there is no clear information in the declaration as to the presence
or order of the type parameters.

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/CAOyqgcV%2B%2BdQu%3DXo4G5owBFbYddRN1hSmwyr4LsF9mJOfVsFaiw%40mail.gmail.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 9:41 AM Rei Roldan  wrote:
>
> I agree, I prefer the D syntax as well.
>
> type!T Point struct {
> x, y int
> data !T
> }
>
> type Transformer interface {
> Transform(!R) !S
> }
>
> func Stringify(s []!T) string {
> }
>
> type Vector []!T
>
> Easy and readable :)

Hmmm, I didn't realize that the declarations and uses were different
in D.  I think it is a good feature of the current design draft that
we use the same sort of syntax at a declaration (func Stringify(type
T)) as at a use (Stringify(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/CAOyqgcU9PWRG0b9J9cDBRncv5qF93_5bVeY8jik1vwPFK%3DHa3w%40mail.gmail.com.

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 7:22 AM christoph...@gmail.com
 wrote:
>
> I would like to insist on considering the D syntax using the ! for generics 
> instantiation.
>
> The first time I saw it, I was puzzled and found it unpleasant. But this is 
> just because it is unfamiliar and not intuitive.
> Once I got used to it, I found it much simple than the C++ templates. In fact 
> I even found it easier to use than the C++ notation.
>
> The thing is that generic instantiation will be very frequent and most of the 
> time with only one template argument. The notation using a simple ! is then 
> much lighter and readable then a notation using parenthesis.
>
> Please, consider and favor the readability and code lightness of the most 
> frequent use with generics which is the instantiation with one type argument.
>
> Compare T!int  with T(int)  or T[int] or T, or A!B!int with A(B(int)) or 
> A[B[int]] or A>.
>
> Please take the time time to experiment it and optimize the most frequent use.
> The D notation gave me the impression that use of generics was simple. Much 
> simpler than with C++.
>
> Go generics made a huge and good simplification by dropping the contracts. 
> Please, follow the same strategy for the instantiation of generics which will 
> be the most frequent occurrence in the code.

Honestly I find A(B(int)) or A[B[int]] to be clearer than A!B!int.  I
don't think A!B!int is horrible.  I just don't think it is the best
possible choice.  Of course that is just my personal opinion.

The sources for the experimental translation tool are available, so
anybody can try the experiment you suggest.  Even easier would be to
rewrite the examples using the D notation, to see how they look.

Ian

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

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

[Ian Lance Taylor]

On Mon, Jul 20, 2020 at 1:23 AM Xie Zhenye  wrote:
>
> Requiring type-information for parsing will brings difficulty for 
> implementing these tools, but not impossible. To solve ambiguity, the only 
> requiring type-information is wether a symbol is a type name or an 
> identifier. A parser package can help this.Since other languages like Java, 
> C#, TypeScript can solve this, it must be a way for Go.

I'm going to try to be very clear.

Being able to parse Go without type information is a fundamental
design decision of the language, made when the project started back in
2007 (before I joined the project myself).

We are not going to change that decision.  If the only way that we can
add generics to Go is to require type information when parsing, then
we will not add generics to Go.

Fortunately the issue does not arise, as there are reasonable syntaxes
that we can use for generics that do not require type information when
parsing.

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

Re: [go-nuts] Allocating lots (e.g. a million) objects on the heap

[Jan Mercl]

Check https://godoc.org/modernc.org/memory, maybe it can be used in this
scenario. Note, using the package concurrently from multiple goroutines
requires coordination, like with a mutex.

On Mon, Jul 20, 2020, 19:35  wrote:

> I have an application where I will be allocating millions of data
> structures, all of the same size. My program will need to run continuously
> and be pretty responsive to
> its network peers.
>
> The data is fairly static, once allocated it will rarely need to be
> modified or deleted.
>
> In order to minimize the garbage collection scanning overhead, I was
> thinking of allocating large blocks on the heap that were a fixed size that
> would hold 20K or so elements
> and then write a simple allocator to hand out pieces of those blocks when
> needed. Instead of having to scan millions of items on the heap, the GC
> would only be scanning 100 or so
> items.
>
> Sound reasonable?  Or does this 'go' against the golang way of doing
> things?
>
> F
>
> --
> You received this message because you are subscribed to the Google 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/0be7d132-71d6-4ff9-a8eb-ca09a94fafeao%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-Vn%2Bg8Yb9%3DX-K_95%3Dt6kQ3gr43kpj9JMwxRk3FMEv00Rw%40mail.gmail.com.

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

[yangw...@gmail.com]

Yes, I'm asking about the size of the archived go distributions.

在2020年7月19日星期日 UTC+8 上午12:11:02 写道：

> 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/874a0d0d-324e-46d1-9c2c-a119889fd00an%40googlegroups.com.

[go-nuts] Allocating lots (e.g. a million) objects on the heap

[netconnect . mary]

I have an application where I will be allocating millions of data 
structures, all of the same size. My program will need to run continuously 
and be pretty responsive to 
its network peers.

The data is fairly static, once allocated it will rarely need to be 
modified or deleted.

In order to minimize the garbage collection scanning overhead, I was 
thinking of allocating large blocks on the heap that were a fixed size that 
would hold 20K or so elements
and then write a simple allocator to hand out pieces of those blocks when 
needed. Instead of having to scan millions of items on the heap, the GC 
would only be scanning 100 or so
items.

Sound reasonable?  Or does this 'go' against the golang way of doing things?

F

-- 
You received this message because you are subscribed to the Google 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/0be7d132-71d6-4ff9-a8eb-ca09a94fafeao%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[Geoff Speicher]

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

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

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

So instead of:

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

We would have:

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

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

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

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

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

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

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

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

Geoff

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

[go-nuts] Re: Generics and parentheses

[Rei Roldan]

I agree, I prefer the D syntax as well.

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

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

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

*type Vector []!T*

Easy and readable :)

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

> I would like to insist on considering the D syntax using the ! for 
> generics instantiation. 
>
> The first time I saw it, I was puzzled and found it unpleasant. But this 
> is just because it is unfamiliar and not intuitive.
> Once I got used to it, I found it much simple than the C++ templates. In 
> fact I even found it easier to use than the C++ notation.
>
> The thing is that generic instantiation will be very frequent and most of 
> the time with only one template argument. The notation using a simple ! is 
> then much lighter and readable then a notation using parenthesis. 
>
> Please, consider and favor the readability and code lightness of the most 
> frequent use with generics which is the instantiation with one type 
> argument.
>
> Compare T!int  with T(int)  or T[int] or T, or A!B!int with A(B(int)) 
> or A[B[int]] or A>. 
>
> Please take the time time to experiment it and optimize the most frequent 
> use. 
> The D notation gave me the impression that use of generics was simple. 
> Much simpler than with C++. 
>
> Go generics made a huge and good simplification by dropping the contracts. 
> Please, follow the same strategy for the instantiation of generics which 
> will be the most frequent occurrence in the code.  
>
> Le mardi 14 juillet 2020 à 23:56:01 UTC+2, gri a écrit :
>
>> We have received a variety of feedback on the generics draft design 
>> 
>>  
>> (blog ). Thanks to everyone 
>> who took the time to read it, play with generics code in the playground 
>> , file issues, and send us their thoughts.
>>
>> Not unexpectedly, many people raised concerns about the syntax, 
>> specifically the choice of parentheses for type parameter declarations and 
>> generic type and function instantiations.
>>
>> A typical computer keyboard provides four easily accessible pairs of 
>> single-character symmetrical "brackets": parentheses ( and ), square 
>> brackets [ and ], curly braces { and }, and angle brackets < and >. Go uses 
>> curly braces to delineate code blocks, composite literals, and some 
>> composite types, making it virtually impossible to use them for generics 
>> without severe syntactic problems. Angle brackets require unbounded parser 
>> look-ahead or type information in certain situations (see the end of this 
>> e-mail for an example). This leaves us with parentheses and square 
>> brackets. Unadorned square brackets cause ambiguities in type declarations 
>> of arrays and slices, and to a lesser extent when parsing index 
>> expressions. Thus, early on in the design, we settled on parentheses as 
>> they seemed to provide a Go-like feel and appeared to have the fewest 
>> problems.
>>
>> As it turned out, to make parentheses work well and for 
>> backward-compatibility, we had to introduce the type keyword in type 
>> parameter lists. Eventually, we found additional parsing ambiguities in 
>> parameter lists, composite literals, and embedded types which required more 
>> parentheses to resolve them. Still, we decided to proceed with parentheses 
>> in order to focus on the bigger design issues.
>>
>> The time has come to revisit this early decision. If square brackets 
>> alone are used to declare type parameters, the array declaration
>>
>> type A [N]E
>>
>> cannot be distinguished from the generic type declaration
>>
>> type A[N] E
>>
>> But if we are comfortable with the extra type keyword, the ambiguity 
>> disappears:
>>
>> type A[type N] E
>>
>> (When we originally dismissed square brackets, the type keyword was not 
>> yet on the table.)
>>
>> Furthermore, the ambiguities that arise with parentheses appear not to 
>> arise with square brackets. Here are some examples where extra parentheses 
>> are not needed with square brackets:
>>
>> using () using []
>>
>> func f((T(int))  func f(T[int])
>>
>> struct{ (T(int)) }   struct{ T[int] }
>>
>> interface{ (T(int)) }interface{ T[int] }
>>
>> [](T(int)){} []T[int]{}
>>
>> To test this better understanding, and to get a feel for this alternative 
>> notation, we will begin to make changes to our prototype implementation 
>> such that it accepts either parentheses or square brackets (only one or the 
>> other) in a generic Go package. Those changes will first appear as commits 
>> to the dev.go2go branch 
>> , and eventually 
>> in the playground .
>>
>> If square brackets don't lead to unforeseen issues, we have another fully 
>> 

Re: [go-nuts] Generics and parentheses

[Peter McKenzie]

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

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

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

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

Re: [go-nuts] Go 2 review process

[David Skinner]

Not having a GitHub account is a non-issue.

   - It is an issue now because the enhancement process is on GitHub issues
   which does not include voting or weighting of votes.

It is a trivial matter to use gohugo.io with a package that integrates
GitHub issues as the repository for comments.
---
But yes I am suggesting that the proposals be on a separate site or
subdomain dedicated to the tracking, triage of enhancement requests.
Approved enhancements get promoted to the GitHub issues as appropriate.

On Mon, Jul 20, 2020 at 10:54 AM Jan Mercl <0xj...@gmail.com> wrote:

> On Mon, Jul 20, 2020 at 1:00 PM Markus Heukelom
>  wrote:
> >
> > Would it be an idea to allow people only to label something as proposal
> if they have at least some support / voucher for the idea? Say N>10 general
> upvotes or 1 upvote from a golang committer?
>
> The problem is that not everyone has a Github account.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/Zqu-HZh3lFg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-VS8vQVQr3AiFCX1OsgyeNYF4%2BY%2BFJ%3Dxu8_eATzRfk%3DFQ%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/CAGe8nGETDFLXyjJgfc3EOnhathv5TNsn_2K3Ro4K3p6sc1ctAg%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

['Axel Wagner' via golang-nuts]

Hi,

ISTM that all those filtering-suggestions are quietly redefining the
problem. The Go team didn't say "we don't have time to read all proposals",
they said "we don't have time to argue every proposal in-depth". So if your
concern was "that is bad, because I want all proposals to get enough
attention", you are not actually helping those proposals - if it doesn't
pass whatever arbitrary threshold you set will still not get an in-depth
discussion. At the same time, you are making it nigh impossible for a
proposal to gain traction, if it doesn't have broad audience appeal - even
if it is a simple and strictly good idea. Lastly, there's still the
possibility of a DoS-Proposal, if it gains some upvotes and people then
insist on an in-depth discussion - even if it's pointless because the Go
team is fully aware they don't want it.

So, IMO, these suggestions are the perfect compromise, in that they leave
everyone equally dissatisfied.

(Also, just FTR, I really dislike formal governance solutions, especially
based on votes, especially if "everybody gets one". In practice, that just
devolves into "the loudest person gets their will" and I'm pretty loud and
could do without that responsibility :) )

On Mon, Jul 20, 2020 at 5:48 PM David Skinner 
wrote:

> I really like Markus Heukelon's suggestion.
>
> There is no need for the Go team to evaluate each proposal, that is a
> silly waste of a valuable and limited resource.
> Having a list of all proposals with voting means that the most popular
> items float to the top and the worst float to the bottom and newbies can
> learn more about the language by reading the list and the comments. We can
> let the community at large do the triage. We can also weight the votes
> based on experience and expertise so:
>
>- Newbies get one vote.
>- Devs like me get 5 votes
>- Daniel Skinner gets 10 votes.
>- TODO(?) Insert Names of other famous people on the go team.
>- Rob Pike gets 1,000 votes
>
>
> # List of All Proposals +
>
>- Proposal #1. Use ternary. Up: 27 Down: 5,362
>
> condition ? value_if_true : value_if_false
> ## Comments
>
>
> On Mon, Jul 20, 2020 at 6:01 AM Markus Heukelom 
> wrote:
>
>> Would it be an idea to allow people only to label something as proposal
>> if they have at least some support / voucher for the idea? Say N>10 general
>> upvotes or 1 upvote from a golang committer?
>>
>> By allowing the "proposal" label, you sort of give people the idea that
>> their idea will be "triaged", to which they then can "appeal". That is in
>> fact very generous. Maybe it is better to only allow a "rfc" label (request
>> for comments). That way you could post your idea, get feedback from the
>> community (including golang fulltimers),  but there's no implied
>> expectation whatsoever to the golang fulltimers to give a go/no-go for the
>> idea.
>>
>>
>> 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
>>> 

Re: [go-nuts] Go 2 review process

[Jan Mercl]

On Mon, Jul 20, 2020 at 1:00 PM Markus Heukelom
 wrote:
>
> Would it be an idea to allow people only to label something as proposal if 
> they have at least some support / voucher for the idea? Say N>10 general 
> upvotes or 1 upvote from a golang committer?

The problem is that not everyone has a Github account.

-- 
You received this message because you are subscribed to the Google 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-VS8vQVQr3AiFCX1OsgyeNYF4%2BY%2BFJ%3Dxu8_eATzRfk%3DFQ%40mail.gmail.com.

Re: [go-nuts] Go 2 review process

[David Skinner]

I really like Markus Heukelon's suggestion.

There is no need for the Go team to evaluate each proposal, that is a silly
waste of a valuable and limited resource.
Having a list of all proposals with voting means that the most popular
items float to the top and the worst float to the bottom and newbies can
learn more about the language by reading the list and the comments. We can
let the community at large do the triage. We can also weight the votes
based on experience and expertise so:

   - Newbies get one vote.
   - Devs like me get 5 votes
   - Daniel Skinner gets 10 votes.
   - TODO(?) Insert Names of other famous people on the go team.
   - Rob Pike gets 1,000 votes


# List of All Proposals +

   - Proposal #1. Use ternary. Up: 27 Down: 5,362

condition ? value_if_true : value_if_false
## Comments


On Mon, Jul 20, 2020 at 6:01 AM Markus Heukelom 
wrote:

> Would it be an idea to allow people only to label something as proposal if
> they have at least some support / voucher for the idea? Say N>10 general
> upvotes or 1 upvote from a golang committer?
>
> By allowing the "proposal" label, you sort of give people the idea that
> their idea will be "triaged", to which they then can "appeal". That is in
> fact very generous. Maybe it is better to only allow a "rfc" label (request
> for comments). That way you could post your idea, get feedback from the
> community (including golang fulltimers),  but there's no implied
> expectation whatsoever to the golang fulltimers to give a go/no-go for the
> idea.
>
>
> 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
>> 

[go-nuts] Proposal for compile-time package overrides support

[Yuriy Yarosh]

Basically I've got some different tcp/ip stack implementations based on 
DPDK and want to be able to replace existing types and methods of the stock 
net package, which would allow to add DPDK support for existing apps 
without any amends as a complete plug'n'play.
Same goes for JSON serialization and similar non-optimized implementations.

Stdlib shouldn't be perfect, but developers should be able to use optimized 
implementations as a drop-in replacement when necessary.

What do you think guys ?

-- 
You received this message because you are subscribed to the Google 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/f3dfc2bf-f650-436f-82c7-fef67003fd5an%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[christoph...@gmail.com]

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

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

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

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

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

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

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

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

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

Re: [go-nuts] [generics] Type embedding in generic types

['Javier Zunzunegui' via golang-nuts]

Coming back at this after more thought & exploration. The fundamental 
problem I see is it introduces complexity, but no value.

Say 
`type I interface {...}`
`type S(type T I) struct {T}`
Then the generic S (before instantiating with a particular T) may implement 
any interface, e.g. in any method on S or any other generic code using S, 
you may have
`_, ok := (interface{}(S(...){})` ).(Whatever)`
and the result of ok depends on what T is used. Without embedding, that is 
strue of T but not S.

# What value did this add?
- You can call methods listed in I directly, e.g. if method Foo is in 
listed I, you can do s.Foo().
=> without embedding using s.I.Foo() is hardly a change.
- You can implement interfaces based on method listed in I directly, e.g. 
if method Foo is listed in I and characterises interface Fooer, you can do 
Fooer(s).
=> without embedding, you can do Fooer(s.I) or if you actually want s 
in the interface, write a generic method Foo in S and keep Fooer(s).
- You can implement interfaces based on method NOT listed in I directly, 
e.g. if method Foo is NOT listed in I, but is defined in some T and 
characterises interface Fooer, you can do Fooer(s) (for s := S(T){...}).
=> without embedding, you can't do this. You can do Fooer(s.I), or 
create a new type for this specificT,  `type X S(T)`, and implement method 
Foo, but let's assume that neither is acceptable. How realistic / in what 
circumstances do you want this? If you require a struct to have a method 
not listed in any contract but present in the type that happens to be 
embedded on this instance of the generic, and want it to be assigned to an 
interface that uses that method but won't accept either the embedded field 
in the interface, nor a separate type derived from it with the additional 
method, I'd say you need to re-evaluate your requirements because you are 
not following any moderatly sensible standards, or at the very least accept 
you are doing something wild and can't use generics for it.

# What did this cost?
- Complexity => the possibility of there being more methods available in a 
struct than listed in its definition is in itself one more thing to think 
about.
- Refactoring => an embedding can't be refactored without a breacking 
change (can't change `type S(type T I) struct {T}` to `type S(type T I) 
struct {T}` + methods in I), since users may be relying on methods not 
present in I. 
- Limits to Tooling: without embedding, `_, ok := (interface{}(S(...){})` 
).(Whatever)` above may always be false and the tooling may be able to 
identify and flag that, with embedding there is nothing it can do since it 
may always be true.

# No arbitrary restrictions
"our hope is to make generic types work as much like ordinary types as 
possible, without arbitrary restrictions"
=> this is indeed a restriction, and I don't know how much that weights 
in the go team's mind regarding future features, etc. But on the other hand 
even allowing embedding in generics isn't quite as pre-generics go either, 
after all you are embedding using the generic's type name (in my example, 
T) and not the name of the actuall type T is instantiated with. In other 
words, the type produced can't be replicated without generics. Banning 
embedding you limit slightly the types you can produce, but at least those 
that are allowed are valid pre-generic go types.

And of course there is also a 'delay decision' argument here: if embedding 
is banned, it can be added later. If it is allowed, the decision is final. 

I do not claim anything dramatic about this feature's significance, like 
generics with fail if embedding is allowed, but also generics will not fail 
because they weren't. So if there is no strong reason for, and there are 
some reasons against, it seems to me the best decision is to ban at first 
and re-evaluate later.
On Tuesday, July 14, 2020 at 11:41:42 AM UTC+2 Javier Zunzunegui wrote:

> Issue openned in https://github.com/golang/go/issues/40199.
>
> Still clarifying my thoughts on embedding types within generics, will 
> postpone this debate while I focus on other parts of the proposal and gain 
> some more experience using the go2 branch. Not calling for any action here 
> at this point. Thanks Ian. 
> On Monday, July 13, 2020 at 7:03:35 PM UTC+2 Ian Lance Taylor wrote:
>
>> On Mon, Jul 13, 2020 at 9:15 AM 'Javier Zunzunegui' via golang-nuts
>>  wrote:
>> >
>> > In the context of Type Parameters - Draft Design#generic-types:
>> >
>> > Type embedding is allowed in the proposed generic changes. Oddly, the 
>> current implementation allows for calling methods in the embedded types but 
>> not using the method to satisfy an interface (here). That seems like a bug 
>> in the implementation.
>> >
>> > More significantly, it allows for calling not just the methods declared 
>> in the interface, but also methods available to the instantiated type but 
>> not part of the interface. Example here. I can't see what is the gain in 

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

[Jake Montgomery]

On Sunday, July 19, 2020 at 1:44:49 PM UTC-4, Steven Blenkinsop wrote:
>
> On Sun, Jul 19, 2020 at 11:43 AM, Jake Montgomery  > wrote:
>
>>  This seems to work: https://go2goplay.golang.org/p/8veymwXYCoZ
>>
>>
>> I'm confused. It panics when I run it now.
>>
>
> Since the outcome is probably cached, I'm not sure how that could be the 
> case. Did you mean to respond to Ian's modified version?
>

They must have been working on the go2 playground. I'm sure it was your 
link, ending in Z, and it complained about MyInt and panicked:

panic: I don't know about type main.MyInt!

But now it works fine.

-- 
You received this message because you are subscribed to the Google 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/80cb0202-a77d-4a6c-adcc-203aa49c9254o%40googlegroups.com.

Re: [go-nuts] compress/flate

[Nick Keets]

Updating those 2 lines would be the least of our problems if this value
ever changes.

On Fri, Jul 17, 2020 at 12:33 PM Jan Mercl <0xj...@gmail.com> wrote:

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

-- 
You received this message because you are subscribed to the Google 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/CAPKajN5-BBQe415-OYze07UbG7xE9naktUfgvM7vFH1Zyf5uNA%40mail.gmail.com.

[go-nuts] Gollvm failed to build hugo

[Yuan Ting]

Hi, I try to build hugo with fresh gollvm but the linker complains that:

# github.com/gohugoio/hugo
/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
split-stack sequence at section 1 offset 0
/usr/bin/ld.gold: error: $WORK/b029/_pkg_.a(gccgo_c.o): failed to match 
split-stack sequence at section 1 offset a6

To reproduce:

git clone https://github.com/gohugoio/hugo.git
cd hugo && go build

Platform: x86_64 ubuntu:20.04
Gollvm build flags:
cmake ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 -
DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_RTTI=On -DLLVM_USE_LINKER=gold -G 
Ninja

-- 
You received this message because you are subscribed to the Google 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/d722a1e8-d205-4c9e-8ae4-623c19dd2946o%40googlegroups.com.

Re: [go-nuts] Go 2 review process

[Markus Heukelom]

Would it be an idea to allow people only to label something as proposal if 
they have at least some support / voucher for the idea? Say N>10 general 
upvotes or 1 upvote from a golang committer? 

By allowing the "proposal" label, you sort of give people the idea that 
their idea will be "triaged", to which they then can "appeal". That is in 
fact very generous. Maybe it is better to only allow a "rfc" label (request 
for comments). That way you could post your idea, get feedback from the 
community (including golang fulltimers),  but there's no implied 
expectation whatsoever to the golang fulltimers to give a go/no-go for the 
idea. 


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/29cad39d-caa3-4315-bedc-bea3a02dc10dn%40googlegroups.com.

[go-nuts] Re: What is the the gccgo equivalent of -X importpath.name=value

[Atilla Filiz]

For archive's sake, let me tell my solution.

I carefully added a preprocessing command into my build steps. Before 
compiling, the following command is run:

sed -E -i 's:(Version\s*=\s*)".*":\1"'$(DOCKER_CLI_VERSION)'":'  \
$(@D)/cli/version/version.go \
&& sed -E -i 's:(GitCommit\s*=\s*)".*":\1"'$(shell git rev-parse 
--short HEAD)'":'  \
$(@D)/cli/version/version.go

The regexes match patterns in 

Version=  "xxx"

Format and replaces the string inside the double quotes while keeping all 
the whitespaces and other relevant characters intact, so repeatedly calling 
the same substitution is safe and does the expected thing. Same for the 
GitCommit, except it uses a shell command instead of an environment 
variable.

Happy Hacking
Atilla

-- 
You received this message because you are subscribed to the Google 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/708d9e10-5e79-4bea-9504-c1a1de0c8640o%40googlegroups.com.

Re: [go-nuts] what is walk(fn *Node) for?

[Jesper Louis Andersen]

>From a quick glance that might be wrong:

It looks like the walk function visits an abstract syntax tree (AST) and
performs checks for the statics part of the compiler. E.g., it finds unused
variables and functions, type-illegal statements and so on. The term "walk"
is used as in that it "walks over the tree and visits each node". The
purpose is likely to set up the AST in a state where it is well-typed. This
simplifies later stages of the compiler as it can assume certain
well-formed principles of the AST structure.

On Mon, Jul 20, 2020 at 4:39 AM xie cui  wrote:

> the go tool compile will call walk, what 's effect of this call?
>
> https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/walk.go#L20
>
> --
> You received this message because you are subscribed to the Google 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/6a65acad-3756-4d77-bf16-23be1a1f9055n%40googlegroups.com
> 
> .
>


-- 
J.

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

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

[Xie Zhenye]

Requiring type-information for parsing will brings difficulty for 
implementing these tools, but not impossible. To solve ambiguity, the only 
requiring type-information is wether a symbol is a type name or an 
identifier. A parser package can help this.Since other languages like Java, 
C#, TypeScript can solve this, it must be a way for Go. 

On Monday, July 20, 2020 at 2:43:53 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye  wrote:
>
>> Gramma of a programming language is not able to be changed after 
>> released. So language design is elegant or not is more important than 
>> difficulty of implementing. 
>>
>> Adding type information in parse time and use angle brackets only affects 
>> compiler and 3rd part tools or IDEs in a short time.
>>
>
> No, it creates lasting downsides. While programming, the normal state of a 
> program is to be broken in some way. And a tool that requires 
> type-information thus can only work on a correctly typed program. So, 
> requiring type-information for parsing will ultimately make many tools less 
> useful by a *lot*. Think about goimports for example - it *inherently* only 
> is used when full type-info is not available, by its very nature.
>
> In general, I really dislike these arguments, that it's just 
> implementation complexity and thus doesn't matter. Humans need to parse the 
> language as well, to read and write it.  And they'll have exactly the same 
> problems. A simple grammar doesn't just simplify things for parser-authors, 
> it also is vital for the people actually using the language.
>  
>
>> Providing parser tools and packages can help 3rd part tools/IDE to 
>> support new gramma. And for professional IDE provider, process generic go 
>> code will not be more difficult than other language like Java, TypeScript 
>> etc.
>>
>> On Wednesday, July 15, 2020 at 6:29:30 AM UTC+8 gri wrote:
>>
>>> Correction: The last paragraph in the post below should have said: "In 
>>> Go, type information is not available at *parse* time". (Of course, 
>>> type information is available at compile time.)
>>>
>>> On Tuesday, July 14, 2020 at 2:56:01 PM UTC-7 gri wrote:
>>>
 We have received a variety of feedback on the generics draft design 
 
  
 (blog ). Thanks to 
 everyone who took the time to read it, play with generics code in the 
 playground , file issues, and send us 
 their thoughts.

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

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

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

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

 type A [N]E

 cannot be distinguished from the generic type declaration

 type A[N] E

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

 type A[type N] E

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

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

 using () using []

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

 

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

['Axel Wagner' via golang-nuts]

On Mon, Jul 20, 2020 at 8:33 AM Xie Zhenye  wrote:

> Gramma of a programming language is not able to be changed after released.
> So language design is elegant or not is more important than difficulty of
> implementing.
>
> Adding type information in parse time and use angle brackets only affects
> compiler and 3rd part tools or IDEs in a short time.
>

No, it creates lasting downsides. While programming, the normal state of a
program is to be broken in some way. And a tool that requires
type-information thus can only work on a correctly typed program. So,
requiring type-information for parsing will ultimately make many tools less
useful by a *lot*. Think about goimports for example - it *inherently* only
is used when full type-info is not available, by its very nature.

In general, I really dislike these arguments, that it's just implementation
complexity and thus doesn't matter. Humans need to parse the language as
well, to read and write it.  And they'll have exactly the same problems. A
simple grammar doesn't just simplify things for parser-authors, it also is
vital for the people actually using the language.


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

[go-nuts] Re: Generics and parentheses

[Xie Zhenye]

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

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

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

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

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

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

[hao dong]

thx. I'll check it.

On Saturday, July 18, 2020 at 12:03:52 AM UTC+8, Jake Montgomery wrote:
>
> 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/0905a00b-9919-43b6-8e5d-f325fab3d782o%40googlegroups.com.