Abstract types cannot have optional references

[hostilefork]

I noticed this when trying out the optional references:

#include "Optional/optional.hpp"

using std::experimental::optional;

class foo {
    virtual void doSomething() = 0;
};

class bar : public foo {
    void doSomething() override {
    }
};

int main() {

    // This works...

    int i = 3;
    int & ir = i;
    optional<int &> oir = ir;

    // And so does this...

    bar b;
    foo & fr = b;
    bar & br = b;
    optional<bar &> obr = br;

    // But this does not...

    optional<foo &> ofr = fr;
}

The error that comes up is:

cannot allocate an object of abstract type ‘foo’ because the following virtual functions are pure within ‘foo’: virtual void foo::doSomething()

One is able to have raw references to an abstract type. So it would seem that an optional reference could be had to an abstract type as well?

[hostilefork]

(Note: example previously wouldn't compile, pasted a bad version somehow. Edited.)

To add another point on this issue, it's possible to re-assign an optional reference such as with

obr = nullopt;
obr = optional<bar &>(br);

Back when I was trying to understand optional better, I asked this question, which I went to link and didn't realize you had been one of the answerers :)

http://stackoverflow.com/questions/11459270/

I composed my own answer ultimately... in which I said:

One's opinion on what the behavior "should" be depends on whether optionals are "a container for zero or one objects of an arbitrary type" or "a thin proxy for a type, with an added feature". The existing code uses the latter idea, and by doing so, it removes half of the "four different behaviors" in the list. This reduces the complexity, and keeps you from unintentionally introducing inefficient usages.

If it is the case that an optional<bar &> is a thin proxy for a type with an added feature...could it be argued that an optional reference should not be re-assignable after its initialization? That would give it a closer behavior to the reference it is wrapping.

[akrzemi1]

cannot allocate an object of abstract type ‘foo’ because the following virtual functions are pure within ‘foo’: virtual void foo::doSomething()

That is most interesting. it looks like member function value_or (which returns by value) makes the instantiation of the entire class invalid. Even though the function is never used I used to think that compiler doesn't try to instantiate members of class templates that it never needs. I will have to learn some more of C++.

[akrzemi1]

If it is the case that an optional<bar &> is a thin proxy for a type with an added feature...could it be argued that an optional reference should not be re-assignable after its initialization? That would give it a closer behavior to the reference it is wrapping.

No, please, not again. The problem of implementing optional reference assignment is not solvable. What you say indeed makes sense. But what the opponents say also makes sense. and these two senses cannot be put together. This is the source of endless discussions, where everybody is right. I cannot point you to any of these discussions as I forgot where tey are. Here is a link to the summary:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3527.html#optional_ref.rationale.assign

[akrzemi1]

I am getting a bit confused. This issue is about "Abstract types cannot have optional references". When I have some spare time I will try to change the signature of value_or to T& optional<T&>::value_or(T&). I believe it will enable abstract types.

[hostilefork]

Will be good to see abstract types work.

I've opened a new issue for the other concern--apologies in advance.