Handling polymorphic errors and values

ghost commented 5 years ago

Does this library support polymorphism on the left-hand-side or the right-hand-side of the Either type? Looking at the code right now, it doesn't look like it because the value will be moved into the supertype. If this is true, I would like to propose this as a feature.

It would probably require some bit-fiddling and storing the data as a raw buffer, but I'm quite certain it can work.

nikhedonia commented 5 years ago

No, the primary use-case of Neither<L,R> is as a value type.

Currently the available options in a polymorphic context are:

to use a reference-wrapper (warning: ownership/scope)
to use a smart-ptr eg. value-ptr
to implement a type-erased wrapper

I'm happy to take a PR but we need to be careful not to compromise the performance and usability in a non-polymorphic context.

ghost commented 5 years ago

@nikhedonia Thanks for the links. The last one in particular was very interesting. I've discovered that for my use-case, a simple value_ptr will do. Maybe this could be added as a remark in the README? Otherwise, I'm closing this issue.

nikhedonia commented 5 years ago

Maybe this could be added as a remark in the README?

Sounds good, We should have some FAQ section as this question comes up quite often.

This shows again how leaky C++ abstractions are:

We have chosen (for performance reasons) to use an union{ L left; R right }; as our base data type. Benefits are:

It maintains value semantics if both types are values
it does not require any heap allocations
we don't require a virtual table and transforming left or right just requires testing a boolean. Test shows this often can get inlined and optimized away.

On the flipside this approach suffers from slicing and the implementation is a bit bit-fiddly.

We could try to get the best of both worlds using the fast-pimpl idiom but I'm afraid that the API would be a bit cumbersome to use

LoopPerfect / neither

Handling polymorphic errors and values #29