Boost logo

Boost :

Subject: Re: [boost] compact_optional -- prompting interest
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2015-10-02 01:04:22

On Thu, Oct 1, 2015 at 3:13 AM, Domagoj Saric <
domagoj.saric_at_[hidden]> wrote:

> The approach with different class templates will actually cause uglier
> user code in the long run (as opposed to a relatively minor _one_time_
> hurdle in only some projects that would be broken by a new defaulted
> parameter) - we'll end up with projects that use optional, pink_optional,
> compact_optional, smelly_optional and hal9000_optional... with someone
> having to track and document where and why each of those is used.

It seems you are saying you want to be able to define some
optional-specific policy specification called Policy, e.g. NeverNan, and
then be able to say optional<float, NeverNan>. This type would behavior
similarly, but not identically, to optional<float>.

It seems the alternative would be to just define OptionalNeverNan<T> as an
alias, using whatever mechanism exists to define it. Users don't have to
care if it is aliasing optional<T, NeverNan> or
compact_optional<T,NeverNan> or whatever.

Calling it optional<T, Policy> instead of something_else<T, Policy> doesn't
really help generic code, since generic code is going to use optional<T>;
it will have no way of knowing what Policy to use. If you have to tell it
the optional policy to use, you could just as well tell it the full
optional type to use. That is why the real win comes from specializing
optional<T> for certain user-defined types T. You would call your type
NeverNan<float> and then (somehow) specialize optional<NeverNan<float>>.

Boost list run by bdawes at, gregod at, cpdaniel at, john at