On 4/2/19 3:55 PM, Peter Dimov via Boost wrote:

Michael Caisse wrote:

...

Note: The repository contains an expected implementation also; however, that is not being considered in this review.

To be clear, I do intend to finish `expected` and provide it as part of the library.

Will it be reviewed separately? Also, IMHO, it's better to have libraries more focused and fine grained. Why not have `expected` as a separate library?

On 4/2/19 4:18 PM, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

On 4/2/19 3:55 PM, Peter Dimov via Boost wrote:

...

Michael Caisse wrote:

...

Note: The repository contains an expected implementation also; however, >> that is not being considered in this review.

To be clear, I do intend to finish `expected` and provide it as part of > the library.

Will it be reviewed separately?

No. If you don't like it, now is the time to reject.

In that case, `expected` should be part of this review and contribute to the final decision.

...

Also, IMHO, it's better to have libraries more focused and fine grained. Why not have `expected` as a separate library?

expected is basically a variant, with a slightly different interface.

It might be implemented like/with variant, but conceptually this is a different component. Just like `optional` is a different component than `variant`. All these components have different use cases and communicate different intentions.

Andrey Semashev wrote:

...

...

Also, IMHO, it's better to have libraries more focused and fine grained. Why not have `expected` as a separate library?

expected is basically a variant, with a slightly different interface.

It might be implemented like/with variant, but conceptually this is a different component. Just like `optional` is a different component than `variant`. All these components have different use cases and communicate different intentions.

It is a different component. That wasn't the question though. The question was, why not have it as a separate library. And the answer is, because the two components share too much of an implementation, and because the design decisions made about one component affect the other (and vice versa - the converting constructor and the subset() member function of `variant` are needed by `expected`).

On Tue, Apr 2, 2019 at 11:37 AM Peter Dimov via Boost wrote:

Zach Laine wrote:

...

Are there any numbers regarding compile- and runtime perf comparisons vs. boost::variant and std::variant(s)?

Yes, see https://github.com/pdimov/variant2/tree/develop/benchmark

Thanks. Zach

pt., 5 kwi 2019 o 02:00 Peter Dimov via Boost napisał(a):

The following is my attempt to give a high-level answer to the questions raised so far.

* First, the submission is a variant type that provides the basic exception safety guarantee and the "never-empty" guarantee. "Never empty", in this context, has the specific meaning that variant has an invariant that it always contains a valid object of one of the given types T1, T2, ..., Tn, and is not allowed any other state.

A possibly-empty variant can be well approximated by adding `monostate` as one of the alternatives. This is recognized by `variant` as the empty state, and is preferentially used as a fallback on exception. If monostate is the first alternative, as is the common case, variant will default-construct to it.

Does this happen *only* when `monostate` is at index 0, or when `monostate` is at any index? I thought from the sources that `monostate` on any index gives the guarantee.

The variant design space is fairly well known, and has been sufficiently explored. Possibly-empty variants (a perfectly legitimate design option) exist. Here is one: http://eggs-cpp.github.io/variant/index.html

However, the type under review is what it is. I understand that everybody has his own preference on design matters, but I've made my choice, and this is what is being reviewed.

* Second, the submission contains a variant-like type `expected`, which at this point does not meet the review criteria of having a test suite, and a finished documentation. (The unfinished documentation is at https://github.com/pdimov/variant2/blob/develop/doc/expected.md.)

I decided to request the review at this time because variant<> is ready for use, and providing it in Boost seemed more practical (people could take advantage of it) than blocking it until I find the time to finish `expected`. And I didn't remove `expected` from the submission in order to allow reviewers to take a look at it and express a preference, if they so choose, on what they feel its fate ought to be.

Traditionally, once libraries are accepted, we don't hold a review on each subsequent addition. But an advance warning couldn't hurt.

So, in your review, you can state what you want done with `expected`. If the submission is accepted in its entirety, I will finish the `expected` test suite and documentation before adding the library to Boost. Or, if the submission is accepted on the condition `expected` not be added without a review, I will remove it before adding the library, and not add it later without a review.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

pt., 5 kwi 2019 o 19:04 Peter Dimov via Boost napisał(a):

Andrzej Krzemienski wrote:

...

...

A possibly-empty variant can be well approximated by adding `monostate` as one of the alternatives. This is recognized by `variant` as the empty state, and is preferentially used as a fallback on exception. If monostate is the first alternative, as is the common case, variant will default-construct to it.

Does this happen *only* when `monostate` is at index 0, or when `monostate` is at any index? I thought from the sources that `monostate` on any index gives the guarantee.

Like std::variant, variant2 always default-constructs to the first alternative. That is, the default constructor of variant initializes a contained value of type T1.

Ah ok; default-constructs to `monostate` when at index 0, and falls back (after exception) to `monostate` if at any index.

On 4/14/19 7:05 PM, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

Beside these mandatory requests, I'd be very interested if Peter presented an updated variant proposal, which doesn't create values out of thin air except if it's monostate.

Since mostly everyone has objected to it - Bjorn has it as an acceptance condition - I'll remove the "default construct a suitable alternative" fallback.

Glad to hear it, thanks!

I'm not yet sure about the monostate special case, as it becomes even more special now. I tend towards removing that too, and just offering the strong guarantee.

I think, monostate is useful - as I said in the review, it is a way to achieve single buffer when you explicitly accept it as a fallback. I'm in favor of keeping it.

On 4/17/19 1:06 AM, Steven Watanabe via Boost wrote:

AMDG

On 4/14/19 10:05 AM, Peter Dimov via Boost wrote:

...

Andrey Semashev wrote:

...

Beside these mandatory requests, I'd be very interested if Peter presented an updated variant proposal, which doesn't create values out of thin air except if it's monostate.

Since mostly everyone has objected to it - Bjorn has it as an acceptance condition - I'll remove the "default construct a suitable alternative" fallback.

I'm not yet sure about the monostate special case, as it becomes even more special now. I tend towards removing that too, and just offering the strong guarantee.

What about this: Only consider default constructing the first type, not any type in the list. This should be much less surprising, because it creates the same state as a default-constructed variant.

I think, that's not much better than default-constructing a random value. There would be no way to prohibit such behavior. OTOH, monostate is a clear marker indicating that such behavior is allowed.