Conditional explicit specification - explicit(constant-expression)

[Tomasz]

I would like to present you and idea to provide a second conditional explicit specifier in the form explicit(constant-expression), that work work in the similar manner like noexcept specifier.

I came up with this idea while reading the N4387: Improving pair and tuple, revision 3 paper. This paper proposes that the pair<T,U> to be implicitly constructible from the expression {e1, e2} if T is implicitly construtible from e1 and U from T2. That means that pair<int,double> may be initialized with {1, 2.0}, while the same expression will not be accepted for pair<std::chrono::second, std::chrono::minutes>. The solution presented in the paper is based on providing the two overloads that differs only in the cosntrain and presence of the explicit specifier (bodies are the same)

template<typename T1, typename T2>
  template<typename U1, typename U2
           typename = std::enable_if_t<
             is_construtible<T1, U1&&>{} && is_construtible<T2, U2&&>{} &&
             is_convertible<U1&&, T1>{} && is_convertible<U2&&, T2>{}
           >>         
pair<T1, T2>::pair(U1&& u1, U2&& u2);

template<typename T1, typename T2>
  template<typename U1, typename U2
           typename = std::enable_if_t<
             is_construtible<T1, U1&&>{} && is_construtible<T2, U2&&>{} &&
             !(is_convertible<U1&&, T1>{} && is_convertible<U2&&, T2>{})
          >>         
explicit pair<T1, T2>::pair(U1&& u1, U2&& u2);

With addition of conditional noexcept, this may be reduced to one overload:
template<typename T1, typename T2>
  template<typename U1, typename U2
           typename = std::enable_if_t<
                          is_construtible<T1, U1&&>{} && is_construtible<T2, U2&&>{}
          >>
explicit(!(is_convertible<U1&&, T1>{} && is_convertible<U2&&, T2>{}))
  pair<T1, T2>::pair(U1&& u1, U2&& u2);

It will also address not such easy to implement case of constructor taking T1 and T2 types explicitly, that is discussed in Implementation Hint section of the paper.

It is change usable for cases on the other classes?
Yes, I consider it usable for any type wrapper object that exposes converting constructor.

Is this change backward compatible?
Yes it adds totally new version of explicit specifier. The no-argument version may be threated as explicit(true), effectively reproducing design of noexcept. Although the parallelism between proposed version of explicit and noexcept stops here - I do not propose to add explicit operator.

It is blocking implementation of the N4387?
No, the paper does no require any certain implementation. Provision of the conditional explicit will open the way to simpler, non-repeatable implementation. It will also simplify the wording.

Does the reduction of writing worth language change?
I think yes. You may notice that the mentioned paper uses some form of conditional explicit specifier (EXPLICIT) to avoid repeating the specification. If we think that is is worth to add conditional explicit to simplify specification, I think that is also worth to have one for code.

Tomasz Kamiński

[Daniel Krügler]

2015-04-24 18:18 GMT+02:00 Tomasz <toma...@gmail.com>:
[..]

[..]

> Does the reduction of writing worth language change?
> I think yes. You may notice that the mentioned paper uses some form of
> conditional explicit specifier (EXPLICIT) to avoid repeating the
> specification. If we think that is is worth to add conditional explicit to
> simplify specification, I think that is also worth to have one for code.

I would like to add that

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4387.html

was intentionally worded (a) not to require a library solution for
this (There where some thoughts of gcc implementers that a built-in
intrinsic __explicit(condition) could be provided to realize that
request) and (b) not to require exactly two overloads (see the
rephrased definition of "/EXPLICIT/"). After I submitted my paper I
planned to write a paper with for a conditional explicit core wording
feature as you describe above.

Thanks,

- Daniel