[Development] Improving toInt, toLong, etc.

[Matthew Woehlke]

On 2014-02-04 15:05, Tony Van Eerd wrote:
>> 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. :-(

Huh. I wonder if that has anything to do with it not being approved :-).

> There are also issues (IMO) on how they define operator>() et al.

Eew... why? ;-)

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.)

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;

(...with any adjustments to const/indirection as desired).

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.)

In fact, that goes double for operator*, since writing '*opt = newval' 
is probably desirable.

>> I hadn't thought of it before; now that I have, I'm strongly leaning toward
>> operator bool() -> isValid() and operator*() -> value().

I should add to that that the above is meant to imply that there is 
*NOT* an operator T().

-- 
Matthew