[Development] Improving toInt, toLong, etc.

[Tony Van Eerd]

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