On Wed, Mar 30, 2016 at 4:57 PM, Benjamin Mahler <[email protected]> wrote:
> Yikes! (3) being not true to me means that I needed non-local reasoning to
> determine the optionality.
Sorry: to clarify, I didn't mean "there is not always a latch" in the
code in question. I meant: "writing 'delete latch;' is not a good way
to imply that there is always a latch, because that code works fine if
latch is optional."
> int fd = -1;
> ...
> if (something) { fd = open(); }
> ...
> if (fd != -1) { close(fd); }
>
> Is there something fundamentally different about new/delete?
To me, `if (ptr != NULL) { delete ptr; }` is distracting, because the
fact that deleting a null pointer is well-defined is very well known.
So I immediately see that and wonder why there is obviously redundant
code. In contrast, close(-1) not having some subtle overloaded meaning
(like kill(-1) does) isn't as obvious.
> Generally we use options for optionality, however we've occasionally
> avoided Option<T*> in favor of T* out of convenience. For these Option<T*>
> variables masquerading as T* variables, it would be great to keep the
> optionality checks to help the reader intuit the optionality, or convert to
> something better than just naked deletes.
I definitely think there is value in distinguishing between optional
and non-optional pointer values, but I don't think no-op statements
like `if (ptr) { delete ptr; }` are the best way to do that. +1 on
using something better than just naked deletes!
Neil
