[variant2] Comments on documentation
The overview states that "variant<T...> is not trivial when all contained types are trivial". Why not? Is this an advantage somehow or an unfortunate limitation? Why is there no tutorial? Why is there no design rationale? Change "variant_npos = -1" into "variant_npos = unspecified" Add a comment about the purpose of valuesless_by_exception(). Without such a comment, the function seems very odd on a "never valueless variant type." The destructor should be marked as noexcept.
Bjorn Reese wrote:
The overview states that "variant<T...> is not trivial when all contained types are trivial". Why not? Is this an advantage somehow or an unfortunate limitation?
It is a limitation. I want to get everything correct first, before introducing additional complexity into the implementation. (And as Andrzej demonstrated, there's still work to do there.)
Change "variant_npos = -1" into "variant_npos = unspecified"
variant_npos is provided for compatibility with std::variant, and it's defined as -1 in the standard.
Add a comment about the purpose of valuesless_by_exception(). Without such a comment, the function seems very odd on a "never valueless variant type."
Yes, agreed, I should note that it's provided for compatibility, same as _npos.
The destructor should be marked as noexcept.
Destructors are noexcept by default.
niedz., 7 kwi 2019 o 14:10 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Bjorn Reese wrote:
The destructor should be marked as noexcept.
Destructors are noexcept by default.
Actually, that is not the case. The noexcept property of a destructor without explicit noexcept annotation is determined by inspecting noexcept property of destructors of non-static data members of the class and its base classes. Since these subobjects are private implementation of your class, and we are not aware of how their destructors are implemented, we cannot determine whether variant's destructor is noexcept or not. Here's an example: ``` class Detail { ~Detail() noexcept(false); }; class Variant { Detail _detail; }; static_assert(std::is_nothrow_destructible_v<Variant> == false); ``` Regards, &rzej;
Andrzej Krzemienski wrote:
niedz., 7 kwi 2019 o 14:10 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Bjorn Reese wrote:
The destructor should be marked as noexcept.
Destructors are noexcept by default.
Actually, that is not the case. The noexcept property of a destructor without explicit noexcept annotation is determined by inspecting noexcept property of destructors of non-static data members of the class and its base classes. Since these subobjects are private implementation of your class, and we are not aware of how their destructors are implemented, we cannot determine whether variant's destructor is noexcept or not.
This is an interesting point. However, the standard doesn't mark the destructors as noexcept, and I'm not sure I see why this same logic doesn't apply to it. http://eel.is/c++draft/variant.dtor http://eel.is/c++draft/optional.dtor http://eel.is/c++draft/any.cons#23 http://eel.is/c++draft/unique.ptr.single.dtor
pon., 8 kwi 2019 o 16:24 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Andrzej Krzemienski wrote:
niedz., 7 kwi 2019 o 14:10 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Bjorn Reese wrote:
The destructor should be marked as noexcept.
Destructors are noexcept by default.
Actually, that is not the case. The noexcept property of a destructor without explicit noexcept annotation is determined by inspecting noexcept property of destructors of non-static data members of the class and its base classes. Since these subobjects are private implementation of your class, and we are not aware of how their destructors are implemented, we cannot determine whether variant's destructor is noexcept or not.
This is an interesting point. However, the standard doesn't mark the destructors as noexcept, and I'm not sure I see why this same logic doesn't apply to it.
http://eel.is/c++draft/variant.dtor http://eel.is/c++draft/optional.dtor http://eel.is/c++draft/any.cons#23 http://eel.is/c++draft/unique.ptr.single.dtor
There is a global requirement for this: http://eel.is/c++draft/requirements#res.on.exception.handling-3 Regards, &rzej;
Andrzej Krzemienski wrote:
This is an interesting point. However, the standard doesn't mark the destructors as noexcept, and I'm not sure I see why this same logic doesn't apply to it.
...
There is a global requirement for this: http://eel.is/c++draft/requirements#res.on.exception.handling-3
Thanks. OK, noexcept it is, then.
On 4/7/19 1:57 PM, Peter Dimov via Boost wrote:
Destructors are noexcept by default.
Why is ~variant_base_impl() marked as noexcept in the implementation? What about my questions about a tutorial and design rationale? Those are genuine questions. I am trying to understand if their absence is deliberate or due to lack of time.
Bjorn Reese wrote:
Destructors are noexcept by default.
Why is ~variant_base_impl() marked as noexcept in the implementation?
Does it matter, really? I don't remember why I marked it noexcept. There's no difference.
What about my questions about a tutorial and design rationale? Those are genuine questions. I am trying to understand if their absence is deliberate or due to lack of time.
The absence of a tutorial and a design rationale are not deliberate, in the sense that I don't believe that the documentation is better without them. Lack of time is more correct. My initial idea was that the target audience for this library consists largely of people who already know they need a variant type, but can't or don't want to use std::variant for some reason. They could make do without a tutorial. Or stated more diplomatically, my estimate was that they would prefer having the library available sooner without a tutorial than waiting for a tutorial that they don't need.
On 8/04/2019 01:07, Peter Dimov wrote:
Bjorn Reese wrote:
What about my questions about a tutorial and design rationale? Those are genuine questions. I am trying to understand if their absence is deliberate or due to lack of time.
The absence of a tutorial and a design rationale are not deliberate, in the sense that I don't believe that the documentation is better without them. Lack of time is more correct.
Absence of a tutorial is fine (I'm sure most people know how variants are supposed to work in general, especially as you're using mostly-compatible interface and behaviour as std::variant), but more motivation and/or design rationale would be nice. Perhaps in lieu of a more focused design rationale section (given time constraints), you could just include a link to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html (as recently posted by Michael)? I assume that your initial arguments there still apply to this implementation, and it seems like useful background information and/or motivation. (Although it then goes on to talk about unrelated things, and obviously at least some of your thinking has changed over time.) And probably most users (like me) would be unaware of the paper otherwise.
participants (4)
-
Andrzej Krzemienski -
Bjorn Reese -
Gavin Lambert -
Peter Dimov