I like this, thanks for pointing me to it. I think that's a good way to go for about half of it; if make / new can be considered as well, that'd be great. I suppose adg's point still stands in terms of gofmt output and a detailed proposal? I agree such a change should only be considered for Go 2.
--dho 2018-02-22 15:37 GMT-08:00 'Bryan Mills' via golang-nuts <golang-nuts@googlegroups.com>: > You might be interested in https://golang.org/issue/12854 for maps, slices, > and structs. > > (It wouldn't help with channels, because there is currently no such thing as > a channel literal.) > > On Thursday, February 22, 2018 at 5:32:40 PM UTC-5, Devon H. O'Dell wrote: >> >> 2018-02-22 14:19 GMT-08:00 Caleb Spare <ces...@gmail.com>: >> > I occasionally run into this, but in my experience it's exclusively with >> > maps: >> >> I think all of the cases I ran into this were for maps and channels. >> >> > - Initializing empty slices is ~never necessary; (in my opinion the >> > "members: []int{}" from the blog post is a code smell). >> >> Probably, but as mentioned in the post, this example was to illustrate >> the point. It was also to keep consistency with the C example. This >> would have been convoluted to do for maps or channels. >> >> > - Channels need initialization but that's where the important buffered >> > vs. >> > unbuffered choice is made, so I'm happy that's explicit. (I suppose you >> > can >> > say the same about initializing maps with a size, but that's fairly rare >> > in >> > my experience.) >> >> That's fair, but why require expressing the type in the call to make? >> You already know the type of the channel; you should only need to >> specify the buffer length (if any). Type inference is so pervasive >> through the rest of the language; the compiler should absolutely be >> able to help here. >> >> For example: >> >> return &ChanThing{c: make(chan T)} >> return &ChanThing{c: make(chan T, 100)} >> return &MapThing{m: make()} >> return &MapThing{m: make(100)} >> >> and >> >> return &ChanThing{c: make()} >> return &ChanThing{c: make(100)} >> return &MapThing{m: make()} >> return &MapThing{m: make(100)} >> >> I think the latter set of examples is much nicer. Yes, you don't see >> _what_ make is allocating, but you knew that if you looked at the >> specification for the type (which you probably already did). Other >> idiomatic expressions already hide this information. For example, c := >> foo.c also doesn't tell you what the type of the assignment is. And >> bar := foo is even more indirect. >> >> --dho >> >> > - If the struct has a nested pointer to another struct type, then having >> > it >> > be nil is definitely what you want since the nested type may or may not >> > have >> > a valid zero value. >> > >> > On Thu, Feb 22, 2018 at 12:02 PM, Devon H. O'Dell <devon...@gmail.com> >> > wrote: >> >> >> >> Hi all, >> >> >> >> It's been some time since I really contributed much of anything to the >> >> project (sorry!), but after 8 years, I'm finally writing Go outside of >> >> the project itself (and outside of porting efforts). I was lamenting >> >> to some coworkers about the lack of a comparable feature to C's >> >> "malloc idiom" and they suggested I write an experience report on it. >> >> I wrote the bulk of the article a month ago, but finally put in some >> >> finishing touches and published. >> >> >> >> For whatever it's worth (probably not much): >> >> https://9vx.org/post/a-malloc-idiom-in-go/ >> >> >> >> --dho >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "golang-nuts" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> >> an >> >> email to golang-nuts...@googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
