[Development] QOptional

[private at bernhard-lindner.de]

In our projects we are using a Result class that also exists as a  
derived Outcome<T> class. That Result class consists of a boolean  
(telling if an error occurred or not) and optional eror code and an  
optional error message. The derived Outcome<T> class adds a value for  
functions that do not only return error information but also a value  
(in case of success).

In the beginning it was just a little helper to avoid nasty  
GetLastError() and/or GetLastErrorString() methods. In a few months  
these two classes turned out to be some of the most useful code we  
ever added to our framework and currently they are used almost  
everywhere as function results and became essential tools for writing  
safe and readable code and were improved in many ways (e.g. as meta  
types and for serialization).

Bot classes do NOT allow any default conversions (neither bool nor  
value nor string) which made their usage a bit more verbose but  
improved readability and safety a lot.

It seems to me that the main purpose of QOptional is similar (except  
that QOptional couldn't carry an error message). I would (almost) kill  
for having something like this officially supported in Qt.

Zitat von Иван Комиссаров <abbapoh at gmail.com>:

> Иван Комиссаров
>
> 21 авг. 2014 г., в 14:37, Robert Knight <robertknight at gmail.com> написал(а):
>
>> I've written a basic Option<T> class with a minimal interface to
>> address the problems with bool* OK args Julien mentioned and found it
>> useful - both
>> in terms of communicating that something may not have a value and also
>> it avoids the need for an invalid/null/empty version of T to be
>> defined.
>>
>> *However*, there is a problem when introducing this into an existing
>> codebase in that it takes time to determine best practices and
>> appropriate usages
>> of an idiom like this, to figure out what methods such a class really
>> needs and what can be left out or written as a separate utility
>> function.
>>
>> The problem with trying to introduce such a class to a foundational
>> library like Qt first is that you don't have this experience and it
>> isn't obvious what
>> API is most important or what idioms will turn out to be widely used.
>> This is how std::future ended up with some pretty basic problems in
>> C++11.
>>
>> I would suggest that a better approach would be to find a real app
>> that is suffering the pains of the existing API - maybe Qt Creator?,
>> introduce the class there first of all
>> and then promote it once it has proven effective.
>
> Good remark:) Actually, we're using plain c++ here at work and we  
> have a simple maybe type (just bool and T with operator* -> and  
> bool; no == or < > operators or different access methods). And you  
> know what? We're using it much more often than you can imagine.  
> Settings class has maybe<T> value<T>(string key) const; method. A  
> lot of functions return maybe just because they can occasionally  
> fail - when dealing with containers it's quite easy to get out of  
> bounds; however crashing is not an option sometimes.
>
> Also, we have an Error class which is {bool ok; union {T value,  
> std::string errosString; }; } - this is used when function want to  
> notify what is the exact problem.
>
> With support of c++11 autos maybe and error classes appeared quite  
> simple and intuitive way to deal with errors. Unlike exceptions that  
> can be caught at any point of the code or error codes that are hard  
> to check - you see what method can fail and you're forced to check  
> if returned value is valid
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development