On Thu, Oct 1, 2015 at 3:13 AM, Domagoj Saric <
domagoj.saric@littleendian.com> 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. 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 or
compact_optional or whatever.
Calling it optional instead of something_else 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.
