2018-02-22 14:19 GMT-08:00 Caleb Spare <cesp...@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.od...@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+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.

Reply via email to