[Development] Improving toInt, toLong, etc.

[Matthew Woehlke]

On 2014-02-04 17:06, Thiago Macieira wrote:
> Em ter 04 fev 2014, às 16:04:11, Matthew Woehlke escreveu:
>> If it were up to me, given an operator* (which is only one more
>> character of typing, after all), I wouldn't provide *any* (additional)
>> convenience access to the value. For roughly this reason; it's a lot of
>> additional implementation effort, highly error prone, and the benefit is
>> almost nil.
>>
>> (Which also means I would consider with QOptional making value() /
>> operator*() the only way to get the interior value.)
>
> Agreed. The implementation of operator== for optionals should only compare
> against another optional. But even that needs magic due to the implicit
> constructor.

Hmm... okay, now I am on the fence here. I guess I could see 
operator==(T) and operator!=(T), which I assume would always return 
false/true (respectively) if the optional is disengaged.

I'd probably resist < and related operators though.

Up to you...

>> Loosely related: I guess if the default behavior of value() on a
>> disengaged optional is to silently construct a default, then the full
>> signature should be:
>>
>> T value(T&& default = {}) const;
>
> You probably mean
>
> 	const T &value(T &&invalidAs = {}) const;

Bleh, that's right, 'default' is a keyword in C++... been writing too 
much Python lately ;-). (I might go with 'ifInvalid' though... 
'invalidAs' just feels odd to me :-).)

Didn't I say that I might have some of the const/indirection wrong? ;-)

That said, does lifetime extension work to extend the life of the 
temporary when the return is the default value and not an engaged value? 
If yes, then the above is preferable; I think I didn't write it that way 
because of that uncertainty.

> But I'm not sure I'm comfortable with requiring rvalue refs for this
> particular piece of code.

Agreed, and I didn't intend for that. Probably having a T&& overload is 
desirable, but there should be a non-C++11 overload provided as a 
fallback. (Again, see comment about adjusting the const/indirection as 
desired.)

(Curiosity question; for the C++11 version, do you write '= {}'? :-) 
...or '= T()' as required by pre-C++11? Not really expressing an 
opinion, just being amused how much more convenient the '= {}' syntax 
is. Albeit moreso when the type is more than one letter.)

>> However, now that I think about it, I still somewhat feel like value()
>> should abort if disengaged, which would also allow a 'T& value()'
>> signature. (Maybe the 'const' version could still be as above, depending
>> whether or not it's felt useful to avoid the return value being a copy.)
>
> I disagree. Existing "value" methods in Qt are all const and do not abort.

I was thinking of 
http://qt-project.org/doc/qt-5/qmap-iterator.html#value :-). (I didn't 
check the code, but I suspect that aborts - perhaps implicitly by 
SEGV'ing - if the iterator is invalid?)

That said, you still raise a fair point... so I guess it depends if you 
think QOptional should be more like a container or an iterator. I can 
live with the former, especially if operator*() returns T&.

-- 
Matthew