This is a question to get some information before thinking about a possible
proposal regarding zero values.
*Could you please let me know the reasons why the zero value of a pointer
is `nil` instead of a pointer to the zero value of what it points to?*
Is it because of performance/memory? Simpl
Thanks for the response!
and the pointer itself would lose the nice property of being a zeroed chunk
> of memory (it wouldn't be a zero value).
>
I see it is a nice property, but I'd say only for people writing the
compiler. I adventure to say that people using the language won't care too
much
Woah! that's a killer reason, the one I was searching for. Thanks for
pointing it out, as you have saved me a lot of time discarding the proposal
I had in mind.
I will need to go in other direction.
El viernes, 14 de febrero de 2020, 15:52:07 (UTC), Brian Candler escribió:
>
> In addition, cons
I thought of this at the beginning, but when I tried to make it work I
realized that I needed to have the following if:
if s != nil {
/* initialize struct or inform it is nil */
}
on every struct method, which eventually defeated the purpose for my use
case.
Out of curiosity: Could you ple
Nil slices are an example of an ideal zero value. When you use them, you
don't need to check for nil -> its zero value is already usable.
Exactly the "slices" case (and the "string" type) is the one inspiring me
to search for more useful zero values for certain types. The two I am
thinking more
Regarding pointers: For me, point number 2 (and 3) is the key that forces
us having some way of expressing emptiness in a pointer. I would say that
point 1 could be optimized by the compiler
Regarding interfaces: Yep! nil-interfaces are a different beast. That's the
reason I focused on just one
Thanks for the example, it is a really good one. At least for me, it is the
first one where I see the real usefulness.
I don't know why, but eventually, I was able to see the parallelism between
maps and slices. All the confusion comes because we have "append" for
slices and not for maps (becau
Well, other languages use the optional/maybe type. It handles sentinel
values pretty well and I don't think they bring new kind of bugs (while
they remove the nil-pointer related bugs).
It is true that they can be a bit cumbersome to use and maybe we lose what
you said: *"the nice and cheap HW
>
> I'd say that's not solving the problem, but making it bigger. Do not
> recover from nil panics, instead fix the nil dereference bug and avoid
> the panic completely.
>
It is never that easy in a medium to big application with a 10+ people team
working on it.
The problem with that reasoni
Thanks a lot for your response. All your points make sense and I can
understand your point of view. I simply have a slightly different point of
view that my experience has shaped.
I see in a programming language as my most important tool. I use it every
single day to make a living. It is becaus
10 matches
Mail list logo
