value_ptr and abstract types as an element_type

[flexferrum]

Not sure about direct PR. Decided to make issue for discussion. Looks like current implementation doesn't allow to hold abstract types in value_ptr. Cloner and Deleters implies that it should be possible but value_or method breaks this possibility:

    element_type value_or( U && v ) const
    {
        return has_value() ? value() : static_cast<element_type>(std::forward<U>( v ) );
    }

It implies that element_type should be able to construct from arbitrary type. For abstract types that's wrong expectation. What if "hide" value_or method under enable_if?

[martinmoene]

@flexferrum, just to let you know I've noticed your question, looking at it in sparsely scattered time ;)

[flexferrum]

NP. :)

[flexferrum]

Also it's good to have type requirements for T in value_ptr. Can it be abstract? Can it be incomplete? Copy-constructable, default-constructable etc. And tests for meeting that requirements as well.

UPD: Personally I vote for less possible restrictions.

[martinmoene]

Added branch issue-8-abstract.

Not making any progress. After 30+ years there's a sense that C++ might perhaps not be for me ;)

@flexferrum Do you have an idea how to advance this?

[flexferrum]

After trying the hot-fix on local Jinja2Cpp branch I realized that value_or breaks the value_ptr semantic at all. Actually (in general) you have no way to predict how to create the pointee value properly, that's why you provide Cloner and Deleter params. So, may be it's better to make value_or as an non-class template function. Or introduce something like get_if. Or extend Cloner interface with CreateDefault (???) member.