>
> Yes, for QOptional you wouldn't want to name it 'isOkay()'. But you
> *will* have the problem of ambiguous implicit conversion with
> QOptional<bool>, which I assume will be allowed even if there is no
> QString::toBool(). Alternatively you could omit implicit value conversion
> entirely and require to use either value() or operator*() (hmm, now I
> wonder if the std::optional proposal had an operator*()...
> it is almost as good as an implicit conversion to the value type, but without
> ambiguity problems, and slightly more explicit while still being much less
> typing than ".value()".)
>
std::optional does have operator*().
It also has the ambiguity of operator bool:
int main()
{
optional<bool> ob = false;
if (!ob) // this if is not the same as....
cout << "false";
if (ob == false) // ... this if
cout << "== false";
return 0;
}
The above prints out....
== false
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3765.pdf (4th
page)
So it was brought up, but the committee didn't change anything in light of it.
:-(
There are also issues (IMO) on how they define operator>() et al.
>
> I hadn't thought of it before; now that I have, I'm strongly leaning toward
> operator bool() -> isValid() and operator*() -> value().
>
That is what std::optional does. Or what std::experimental::optional does or
will do. It is not part of the standard yet, nor C++14. It is just a TS.
It would be great for Qt to have a QOptional so as to build more experience of
its usage in the wild. Of course there is already boost::optional, which
std::optional is largely based on, but more flavours would be appreciated. It
is in a TS specifically because we realize we need more experience on some of
these subtle issues.
Tony
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
