Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-09-27 06:35:59

On September 26, 2015 5:34:59 PM EDT, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:
> On Sat, Sep 26, 2015 at 7:52 PM, Andrzej Krzemienski
> <akrzemi1_at_[hidden]> wrote:
> 
> > I am not particularly tied to name compact_optional. I can be
> persuaded to
> > rename it. On the other hand, I am not in favor of any names
> containing
> > "null". I am not an English speaker, but no me "null" sounds like
> "numeric
> > value zero", which makes sense for the pointer, but not for
> something that
> > just is not. Maybe "singular" or "special".
> 
> Well, I'm not a native speaker but AFAIK null does literally mean zero
> in English. However, in the programming domain I don't see null as
> something that is necessarily equivalent to a zero value. It's more
> like a 'special value' to me. E.g. in databases null is a special
> value that has no connection to zero at all. Even in C++ null pointers
> are not required to have zero value as the underlying implementation.

FWIW, in my experience as a native English speaker, null is rarely synonymous with zero. It connotes having no value or (legal) power.

> But I'm not insisting on nullable<>. There's also a close alternative
> of nilable<>. Singular is the characteristic of a particular value,
> not the type or range of values, so it's difficult to compose a name
> from it (I believe, 'singularable' is not a word). Special is too
> generic, IMHO. We can go a different way: nav_adapter<> (where nav
> stands for not-a-value) or singular_adapter<>. Although I like it less
> than nullable.

"nav" is a common abbreviation for "navigation" and "navigator", so that would easily cause confusion.

> >> 5. A suggestion: add evp_zero and evp_empty policies. The first
> uses
> >> literal zero as the special value and can be used with numeric
> (integer and
> >> fp) and pointer types. The second uses a default constructed value
> as the
> >> magic value and a member empty() function to test for magic value.
> This
> >> could be useful with containers, strings and ranges.
> >
> > Agreed on evp_empty, but I fail to see the advantage of evp_zero
> over the
> > already existing evp_value_init. The later uses the value
> initialized T,
> > which already is zero for ints, floats and pointers. Or do you
> expect the
> > comparison to literal 0 to be faster?
> 
> Oh, it didn't occur to me until your reply that evp_value_init already
> covers the evp_zero use cases. Ok, good, no need for evp_zero.

An evp_zero_init (or evp_zero_initialization) would cover zeroes for built-in types and default construction of UDTs.

___
Rob

(Sent from my portable computation engine)