On 2019-08-12 14:34, Allan Sandfeld Jensen wrote:
On Monday, 12 August 2019 14:21:25 CEST Ville Voutilainen wrote:
On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen <k...@carewolf.com>
wrote:
> explicit(bool): We use some ugly patterns in places to simulate this.
Can you point me to those? I do know what such patterns are in
general, std::optional and std::tuple
are full of it. :)
https://code.woboq.org/qt5/qtbase/src/corelib/text/qbytearray.h.html#448
https://code.woboq.org/qt5/qtbase/src/corelib/tools/qscopedpointer.h.html#126
https://code.woboq.org/qt5/qtbase/src/corelib/tools/
qsharedpointer_impl.h.html#570
Are a few I just found again.
That's explicit operator bool(), and we can already use it, except we
can't as it breaks SC: with Object using the safe-bool idiom ("ugly
pattern") the following works:
bool is_null(Object &o) { return o; }
but with Object using explicit operator bool, it doesn't:
bool is_null(Object &o) { return bool(o); }
Peppe tried to do the change to our pointer classes some years ago and
found that it broke too much existing code.
explicit(bool), otoh, is about making the explicit keyword dependent on
a compile-time constant, as in
template <typename T>
class optional {
~~~
template <typename Arg>
// didn't find a version of is_convertible for more than one
explicit(!std::is_convertible_v<Arg, T>)
optional(Arg &&arg) : m_store(std::forward<Arg>(arg)) {}
~~~
};
The ctor should be explicit iff the corresponding ctor of T(Arg) is. The
implementation uses direct initialisation, so it "eats" explicit; not
making the 'optional' ctor explicit open a hole in the type system that
wasn't intended.
If you don't have explicit(bool), you need to duplicate the ctor, once
with explicit and once without, and sfinae the one out that doesn't
apply, given the Arg.
HTH,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
