clear()
Closed this issue · 4 comments
I saw that you added the member function clear() (which I like). However on http://en.cppreference.com/w/cpp/experimental/optional the clear member function is not mentioned. So I was wondering; who is correct?
Oh, clear is not public :-(
Is there a reason for not having a public clear (or reset without any arguments) member function? This would make it more in-line with the containers, and
value.clear();
is more clear to me than for example
value = nullopt;
Hi, the reference in this case is the Library Fundamentals TS (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4082.pdf), there is no function clear() there.
The reason for not having v.clear() is that it would have been redundant with v = nullopt. Since we do not provide the full container interface (like begin(), end()) offering only clear() doesn't sound that convincing.
I understand that the named function may be more attractive than an operator overload, but this is how optionalis designed: it prefers clever operators overloads. The same is the case for:
if (v != nullopt) ...
if (v) ...whereas someone might prefer
if (v.is_initialized()) ...Just a design choice...
Hello Andrzej,
Thank you for your reply. Personally I would have preferred that these classes would be more consistent and we would not so many different patterns.
For example "any" (which is also part of the Library Fundamentals TS) has a member function clear() and there is no nullany. It is difficult for me to understand why "v = nullopt" was chosen for optional, but "v.clear()" was chosen for any.
(And different people doing the original design of both classes shouldn't be the correct answer on that question... I would have hoped that the design would be streamlined by the commitee ;-) )
Hi, there are some more incoherences between optional and any. Please take a look at this draft [1] DXXXX- Adding Coherency Between any and optional. It proposes to make both interfaces more coherent. However I'm not for adding more and more functions to optional or any, future, expected, variant, .... An alternative is to define customizable free functions a la begin/end that could be used to adapt the interface to each specific type. The main problem is that for the time been the C++ committee is not too much for adding more and more customizable points.
I don't see optional nor any as a container, but I could see optional as a range that could be empty or have an single element, so having a customization for begin/end will be fine. Note that this doesn't allows to add elements to the optional range, just to inspect the possible element as if it were a range.
Anyway, any comment about the proposal is welcome.