[Development] QOptional

[Bo Thorsen]

Den 21-08-2014 11:43, Иван Комиссаров skrev:
>
> Иван Комиссаров
>
> 21 авг. 2014 г., в 13:25, Simon Hausmann <simon.hausmann at digia.com> написал(а):
>
>> On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
>>
>> To be honest: I find the "bool ok" variant much easier to read.
>>
>> "if (value)" on an auto variable can mean so many things. In the
>> above example you could very easily think: Ah, toInt returns an int,
>> so the type of "value" is probably int, so if (value) checks if it's non-zero.
>>
>> I don't think that makes for a very intuitive API. Yes, it's less to type, but
>> less isn't always more :)
>
> Writing toInt() method itself becomes more easier too:
> QOptional<int> toInt()
> {
>     ....
>     if (error)
>        return QNothing();
>      return value;
> }
>
> Compare with
> int toInt(bool *ok = 0)
> {
>     ....
>     if (ok)
>         *ok = !error;
>     if (error)
>        return 0;
>
>      return value;
> }
>
> Also, using Optional/Maybe types can lead to a more functional-style code - you can store error state in a member variable or return using bool as shown above (which leads to extra code if (error) { ok = false; return T(); }) or you can use maybe-type. I used this approach for parsing network messages - without optionals i had to use a reentrant class that stored an error state, with optionals i removed the entire class and replaced it with a pack of thread-safe functions (taking QByteArray and returning Optional<QVariantList> where QVariantList is parsed data (yes, empty list is valid))

I have been monitoring this thread with a bit of scepticism.

And I'm sorry, but I don't see this as an improvement. It seems more 
like clutter with classes instead of clutter in the syntax supported 
version. The new object based version seems to me like overengineering 
to solve a non-existing problem. And it's even slower than the current 
version, not that I see this as an important argument, though.

I do support the argument to not implement a class that will come with 
stl later. Yes, there might be a slight advantage to introduce it now, 
in case there are cases in Qt where those classes could help solve real 
problems instead of the above example. But if those conversion functions 
is all you can come up with, I think it's a bad idea to get ahead of stl 
here. So what if we have to wait for Qt 7 instead of Qt 6 to use 
std::optional, if the gain is marginal anyway? *Please* don't add more 
stl copied classes just because the stl committee is slow.

Please stay with the current implementation.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu