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