Allow initialization of optionals from convertible type U (or optional<U>)

[hostilefork]

Currently it is possible to initialize one optional from another if their types match exactly. But one should ideally be able to initialize one optional from another if the types are convertible:

#include <memory>
#include "Optional/optional.hpp"

using std::experimental::optional;
using std::experimental::make_optional;
using std::shared_ptr;

int main() {
    shared_ptr<int> i (new int (1020));
    shared_ptr<int const> ic = i;

    optional<shared_ptr<int>> oi = i;
    optional<shared_ptr<int>> oi2 = oi;

    // Everything up to here works, but these fail...
    optional<shared_ptr<int const>> oic = i;
    optional<shared_ptr<int const>> oic2 = oi;
}

The error you get on oic is:

conversion from ‘std::shared_ptr<int>’ to non-scalar type ‘std::experimental::optional<std::shared_ptr<const int>>’ requested

...and on oic2 you get:

conversion from ‘std::experimental::optional<std::shared_ptr<int>>’ to non-scalar type ‘std::experimental::optional<std::shared_ptr<const int>>’ requested

Similar arguments apply for cases like:

class Foo {};
class Bar : public Foo {};

optional<unique_ptr<Foo>> makeOptionalFoo() {
    return unique_ptr<Bar>(new Bar);
}

Which doesn't currently work, but I think it should.

[akrzemi1]

It is just not clear what should happen in the following situation:

struct Tool
{
  Tool(int); // ctor 1
  Tool(optional<int>); // ctor 2
};

optional<int> oi = 1;
optional<Tool> ot = oi;

Which constructor of Tool should be called and why?

[hostilefork]

I would say that it's a bad design to have two method signatures that differ only in optionality for a type. Interface-wise that sounds like it should be ambiguous...?

[akrzemi1]

I do not know. I think I will rise this to the community and let other people speak. This looks like something that might become a controversial issue.

[hostilefork]

(Note: my code needed to account for the non-optional initializations as well, to be a good demonstration. Fixed.)

With the suggested change: your Tool case would favor the int constructor over the optional<int> constructor, for the initialized case. If the int constructor were removed, it would then resort to the optional<int> case.

I suppose one could make a reasonable argument that if it's an optional that you know to have a value...then a known integer constructor should be preferred. It could be seen as an argument from specificity. Certainly no weirder than resolving the ambiguity here on a shared_ptr<int>...

struct Tool
{
    Tool(shared_ptr<int>) {
        std::cout << "non-const constructor";
    }

    Tool(shared_ptr<int const>) {
        std::cout << "const constructor";
    }
};

shared_ptr is a good parallel...because I think the usefulness of being able to negotiate the compatibility of the pointer types far outweighs the value of more specific selections. To me, optional is very much in that spirit.

My own usage has several coercible classes that I can assign to each other normally, and I'd hate to be forced to extract them. I have many cases of foo<x> which is coercible to foo<x const> (but not vice-versa). Without the adjustment, to assign convertible optionals to one another:

optional<foo<x const>> convertFoo(optional<foo<x>> input) {
    if (not input) return nullopt;
    foo<x const> output = input;
    return output;
}

I'd think there'd have to be a very good reason to require that. Following the rule of not having an interface that differs only in optionality seems a small price to pay. Especially considering that the behavior if you break the rule isn't outlandish.

It may also be able to change the rule to favor the optional<int> over the int, if that's what's preferred. As I say--I could live with it either way, because I don't think it's a good idea to have both in the first place.

[akrzemi1]

See this discussion: https://groups.google.com/a/isocpp.org/d/topic/std-proposals/RTUK2xO0tzs/discussion

[hostilefork]

Cool, thanks. Pretty much any of those work for me, as long as the basic behavior is available!

[wanchaol]

Hi @akrzemi1, any updates on this one? I am seeing https://en.cppreference.com/w/cpp/utility/optional/optional, the library is missing constructor 8. Do you have any plan on adding it?