--001a114f2562caab9f053d9e2725
Content-Type: text/plain; charset=UTF-8

A colleague suggested the following idea today:

void f(explicit T x);

explicit as a decl-specifier on a function parameter indicates that
standard and user-defined conversions should be suppressed on an argument
to that parameter.  This would make, for example, the following ill-formed:

   void g(explicit int x);

   double d = 42.0;

   int main() {
     g(d); // ERROR: d is not an int
   }

It would also be useful in overload resolution as the explicit version
wouldn't be considered except for an exact match on the type.

Anyone find this interesting?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKkZmmdBS36gOoEqKrEF%2BTKyipyGeDh6obPQdG3Vc%3D6EA%40mail.gmail.com.

--001a114f2562caab9f053d9e2725
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A colleague suggested the following idea today:<div><br></=
div><div>void f(explicit T x);</div><div><br></div><div>explicit as a decl-=
specifier on a function parameter indicates that standard and user-defined =
conversions should be suppressed on an argument to that parameter.=C2=A0 Th=
is would make, for example, the following ill-formed:</div><div><br></div><=
div>=C2=A0 =C2=A0void g(explicit int x);</div><div><br></div><div>=C2=A0 =
=C2=A0double d =3D 42.0;</div><div><br></div><div>=C2=A0 =C2=A0int main() {=
</div><div>=C2=A0 =C2=A0 =C2=A0g(d); // ERROR: d is not an int</div><div>=
=C2=A0 =C2=A0}</div><div><br></div><div>It would also be useful in overload=
 resolution as the explicit version wouldn&#39;t be considered except for a=
n exact match on the type.</div><div><br></div><div>Anyone find this intere=
sting?</div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKkZmmdBS36gOoEqKrEF%2BTKyipy=
GeDh6obPQdG3Vc%3D6EA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKk=
ZmmdBS36gOoEqKrEF%2BTKyipyGeDh6obPQdG3Vc%3D6EA%40mail.gmail.com</a>.<br />

--001a114f2562caab9f053d9e2725--

.

On quarta-feira, 28 de setembro de 2016 23:46:04 PDT Andrew Tomazos wrote:
> A colleague suggested the following idea today:
>
> void f(explicit T x);
>
> explicit as a decl-specifier on a function parameter indicates that
> standard and user-defined conversions should be suppressed on an argument
> to that parameter.  This would make, for example, the following ill-formed:
>
>    void g(explicit int x);
>
>    double d = 42.0;
>
>    int main() {
>      g(d); // ERROR: d is not an int
>    }
>
> It would also be useful in overload resolution as the explicit version
> wouldn't be considered except for an exact match on the type.
>
> Anyone find this interesting?

Yes. It has come up recently when discussing serialisation operators. For
example, for QDataStream, you'd write the following for a given type MyType:

 void operator<<(QDataStream &s, const MyType &t);

The problem with that is that another type that converts to MyType by either
constructor, cast operator or by derivation, suddenly can also get serialised,
when in reality it probably should have been a compilation error because the
type in question didn't have its serialisation operator defined.

A workaround for this is to use a template and make the function a template
specialisation.

PS: the issue in question turned out to be a case of those famous last words,
"no one is going to derive from my type!"

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12455530.tfTrl4VhGV%40tjmaciei-mobl1.

.

------=_Part_101_1572314375.1475137158519
Content-Type: multipart/alternative;
 boundary="----=_Part_102_1074230375.1475137158519"

------=_Part_102_1074230375.1475137158519
Content-Type: text/plain; charset=UTF-8

Just a quick test, this seems to work for user-provided conversions

#include <iostream>

struct D
{
    int i = 12;
};

struct H
{
    operator D() { return d; }

    D d;
};

template<class T>
struct Guard
{
    Guard(const T& v) : v(v) {}
    operator const T& () const { return v; }
    const T& v;
};

void _func(const D& val)
{
  std::cout << val.i;
}

void func(const Guard<D>& val)
{
  return _func(val);
}

int main()
{
    D d;
    H h;

    func(h); //< will fail, needs explicit D

    return 0;
}

Granted, it will *not *work for the OP example using int and double
(assuming func signature is changed of course).

Question. Can some template enable_if magic be applied to the Guard class
to improve it?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5c4cd064-37da-4bf2-b39d-291eae92dd4b%40isocpp.org.

------=_Part_102_1074230375.1475137158519
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just a quick test, this seems to work for user-provided co=
nversions<div><br></div><div><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
 solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><font color=3D"#660066"><div class=3D"sub=
prettyprint">#include &lt;iostream&gt;</div><div class=3D"subprettyprint"><=
br></div><div class=3D"subprettyprint">struct D</div><div class=3D"subprett=
yprint">{</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 int i =3D 12;</d=
iv><div class=3D"subprettyprint">};</div><div class=3D"subprettyprint"><br>=
</div><div class=3D"subprettyprint">struct H</div><div class=3D"subprettypr=
int">{</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 operator D() { retu=
rn d; }</div><div class=3D"subprettyprint">=C2=A0 =C2=A0=C2=A0</div><div cl=
ass=3D"subprettyprint">=C2=A0 =C2=A0 D d;</div><div class=3D"subprettyprint=
">};</div><div class=3D"subprettyprint"><br></div><div class=3D"subprettypr=
int">template&lt;class T&gt;</div><div class=3D"subprettyprint">struct Guar=
d</div><div class=3D"subprettyprint">{</div><div class=3D"subprettyprint">=
=C2=A0 =C2=A0 Guard(const T&amp; v) : v(v) {}</div><div class=3D"subprettyp=
rint">=C2=A0 =C2=A0 operator const T&amp; () const { return v; }</div><div =
class=3D"subprettyprint">=C2=A0 =C2=A0 const T&amp; v;</div><div class=3D"s=
ubprettyprint">};</div><div class=3D"subprettyprint"><br></div><div class=
=3D"subprettyprint">void _func(const D&amp; val)</div><div class=3D"subpret=
typrint">{</div><div class=3D"subprettyprint">=C2=A0 std::cout &lt;&lt; val=
..i;</div><div class=3D"subprettyprint">}</div><div class=3D"subprettyprint"=
><br></div><div class=3D"subprettyprint">void func(const Guard&lt;D&gt;&amp=
; val)</div><div class=3D"subprettyprint">{</div><div class=3D"subprettypri=
nt">=C2=A0 return _func(val);</div><div class=3D"subprettyprint">}</div><di=
v class=3D"subprettyprint"><br></div><div class=3D"subprettyprint">int main=
()</div><div class=3D"subprettyprint">{</div><div class=3D"subprettyprint">=
=C2=A0 =C2=A0 D d;</div><div class=3D"subprettyprint">=C2=A0 =C2=A0 H h;</d=
iv><div class=3D"subprettyprint">=C2=A0 =C2=A0=C2=A0</div><div class=3D"sub=
prettyprint">=C2=A0 =C2=A0 func(h); //&lt; will fail, needs explicit D</div=
><div class=3D"subprettyprint">=C2=A0 =C2=A0=C2=A0</div><div class=3D"subpr=
ettyprint">=C2=A0 =C2=A0 return 0;</div><div class=3D"subprettyprint">}</di=
v></font></div></code></div><br>Granted, it will <i>not </i>work for the OP=
 example using int and double (assuming func signature is changed of course=
).</div><div><br></div><div>Question. Can some template enable_if magic be =
applied to the Guard class to improve it?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5c4cd064-37da-4bf2-b39d-291eae92dd4b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c4cd064-37da-4bf2-b39d-291eae92dd4b=
%40isocpp.org</a>.<br />

------=_Part_102_1074230375.1475137158519--

------=_Part_101_1572314375.1475137158519--

.

On 29 September 2016 at 07:46, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> A colleague suggested the following idea today:
>
> void f(explicit T x);
>
> explicit as a decl-specifier on a function parameter indicates that standard
> and user-defined conversions should be suppressed on an argument to that
> parameter.  This would make, for example, the following ill-formed:
>
>    void g(explicit int x);
>
>    double d = 42.0;
>
>    int main() {
>      g(d); // ERROR: d is not an int
>    }
>
> It would also be useful in overload resolution as the explicit version
> wouldn't be considered except for an exact match on the type.
>
> Anyone find this interesting?


The idea isn't new, but I'm not sure whether there's ever been an
actual proposal for it. Why should it be a language
feature? Why not just write an explicit-wrapper as a library facility(*)?

(*) One thing that comes to mind is that it would be feasible to
modify just the header-declaration without having
to modify the source-definition, without any linker impact.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYq-msMpa%2Bd7_UEpjyreiED_ji7FYat9vwcWQf1EDdXrQ%40mail.gmail.com.

.

------=_Part_266_1732207723.1475138318138
Content-Type: multipart/alternative;
 boundary="----=_Part_267_42562008.1475138318138"

------=_Part_267_42562008.1475138318138
Content-Type: text/plain; charset=UTF-8

On Thursday, September 29, 2016 at 5:46:06 AM UTC+1, Andrew Tomazos wrote:
>
> A colleague suggested the following idea today:
>
> [snip]

> explicit as a decl-specifier on a function parameter indicates that
> standard and user-defined conversions should be suppressed on an argument
> to that parameter.  This would make, for example, the following ill-formed:
>
> [snip]

> It would also be useful in overload resolution as the explicit version
> wouldn't be considered except for an exact match on the type.
>
> Anyone find this interesting?
>
>
The idea is interesting, although I'm not sure that it is worth a language
feature. The usual workaround is to write a wrapper template for 'g' and
static_assert (or SFINAE) that the deduced type is the same as the expected
type.



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cbd77edb-084d-45ab-9a1f-01a0aaec1788%40isocpp.org.

------=_Part_267_42562008.1475138318138
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, September 29, 2016 at 5:46:06 AM UTC+1, Andre=
w Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">A colleague suggested the following idea today:<div><br></div></div></bl=
ockquote><div>[snip] <br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div>explicit as a decl-specifier on a function parameter=
 indicates that standard and user-defined conversions should be suppressed =
on an argument to that parameter.=C2=A0 This would make, for example, the f=
ollowing ill-formed:</div><br></div></blockquote><div>[snip] <br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It would als=
o be useful in overload resolution as the explicit version wouldn&#39;t be =
considered except for an exact match on the type.</div><div><br></div><div>=
Anyone find this interesting?</div><div><br></div></div></blockquote><div><=
br>The idea is interesting, although I&#39;m not sure that it is worth a la=
nguage feature. The usual workaround is to write a wrapper template for &#3=
9;g&#39; and static_assert (or SFINAE) that the deduced type is the same as=
 the expected type.<br><br>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cbd77edb-084d-45ab-9a1f-01a0aaec1788%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cbd77edb-084d-45ab-9a1f-01a0aaec1788=
%40isocpp.org</a>.<br />

------=_Part_267_42562008.1475138318138--

------=_Part_266_1732207723.1475138318138--

.

------=_Part_82_1968703851.1475139256950
Content-Type: multipart/alternative;
 boundary="----=_Part_83_422489773.1475139256950"

------=_Part_83_422489773.1475139256950
Content-Type: text/plain; charset=UTF-8


On Thursday, September 29, 2016 at 11:19:18 AM UTC+3, mihailn...@gmail.com
wrote:
>
> Just a quick test, this seems to work for user-provided conversions
>
> #include <iostream>
>
> struct D
> {
>     int i = 12;
> };
>
> struct H
> {
>     operator D() { return d; }
>
>     D d;
> };
>
> template<class T>
> struct Guard
> {
>     Guard(const T& v) : v(v) {}
>     operator const T& () const { return v; }
>     const T& v;
> };
>
> void _func(const D& val)
> {
>   std::cout << val.i;
> }
>
> void func(const Guard<D>& val)
> {
>   return _func(val);
> }
>
> int main()
> {
>     D d;
>     H h;
>
>     func(h); //< will fail, needs explicit D
>
>     return 0;
> }
>
> Granted, it will *not *work for the OP example using int and double
> (assuming func signature is changed of course).
>
> Question. Can some template enable_if magic be applied to the Guard class
> to improve it?
>


This ctor seems to fix the OP problem as well

    template <typename TT,
              typename = std::enable_if_t<std::is_same_v<T,
std::decay_t<TT>>>
    >
    Guard(TT&& v) : v(std::forward<TT>(v)) {}


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2a5147cd-0a72-4483-820b-6055fddeddc0%40isocpp.org.

------=_Part_83_422489773.1475139256950
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Thursday, September 29, 2016 at 11:19:18 AM UTC+3, =
mihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">Just a quick test, this seems to work for user-provided conve=
rsions<div><br></div><div><div style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:=
break-word"><code><div><font color=3D"#660066"><div>#include &lt;iostream&g=
t;</div><div><br></div><div>struct D</div><div>{</div><div>=C2=A0 =C2=A0 in=
t i =3D 12;</div><div>};</div><div><br></div><div>struct H</div><div>{</div=
><div>=C2=A0 =C2=A0 operator D() { return d; }</div><div>=C2=A0 =C2=A0=C2=
=A0</div><div>=C2=A0 =C2=A0 D d;</div><div>};</div><div><br></div><div>temp=
late&lt;class T&gt;</div><div>struct Guard</div><div>{</div><div>=C2=A0 =C2=
=A0 Guard(const T&amp; v) : v(v) {}</div><div>=C2=A0 =C2=A0 operator const =
T&amp; () const { return v; }</div><div>=C2=A0 =C2=A0 const T&amp; v;</div>=
<div>};</div><div><br></div><div>void _func(const D&amp; val)</div><div>{</=
div><div>=C2=A0 std::cout &lt;&lt; val.i;</div><div>}</div><div><br></div><=
div>void func(const Guard&lt;D&gt;&amp; val)</div><div>{</div><div>=C2=A0 r=
eturn _func(val);</div><div>}</div><div><br></div><div>int main()</div><div=
>{</div><div>=C2=A0 =C2=A0 D d;</div><div>=C2=A0 =C2=A0 H h;</div><div>=C2=
=A0 =C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 func(h); //&lt; will fail, needs e=
xplicit D</div><div>=C2=A0 =C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 return 0;</=
div><div>}</div></font></div></code></div><br>Granted, it will <i>not </i>w=
ork for the OP example using int and double (assuming func signature is cha=
nged of course).</div><div><br></div><div>Question. Can some template enabl=
e_if magic be applied to the Guard class to improve it?</div></div></blockq=
uote><div><br></div><div><br></div><div>This ctor seems to fix the OP probl=
em as well</div><div><br></div><div><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 template &lt;typename TT,</div><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 typename =3D std::enable_if_t=
&lt;std::is_same_v&lt;T, std::decay_t&lt;TT&gt;&gt;&gt;</div><div class=3D"=
subprettyprint">=C2=A0 =C2=A0 &gt;</div><div class=3D"subprettyprint">=C2=
=A0 =C2=A0 Guard(TT&amp;&amp; v) : v(std::forward&lt;TT&gt;(v)) {}</div></d=
iv></code></div><div><br></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2a5147cd-0a72-4483-820b-6055fddeddc0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a5147cd-0a72-4483-820b-6055fddeddc0=
%40isocpp.org</a>.<br />

------=_Part_83_422489773.1475139256950--

------=_Part_82_1968703851.1475139256950--

.

--001a114407a23b9744053da1a15f
Content-Type: text/plain; charset=UTF-8

But it is perfectly doable on the call site only, so works for
nontemplates. Sfinae, concepts etc require templates, no?

What would you guys think about templates that restrict only variety of
call sites using concepts, but that keep the function body clear of the
argument type (and the parameter has to be fixed nontemplated type). Then
separate compilation should still work.

Am 29.09.2016 10:38 schrieb "Giovanni Piero Deretta" <gpderetta@gmail.com>:
>
> On Thursday, September 29, 2016 at 5:46:06 AM UTC+1, Andrew Tomazos wrote:
>>
>> A colleague suggested the following idea today:
>>
> [snip]
>>
>> explicit as a decl-specifier on a function parameter indicates that
standard and user-defined conversions should be suppressed on an argument
to that parameter.  This would make, for example, the following ill-formed:
>>
> [snip]
>>
>> It would also be useful in overload resolution as the explicit version
wouldn't be considered except for an exact match on the type.
>>
>> Anyone find this interesting?
>>
>
> The idea is interesting, although I'm not sure that it is worth a
language feature. The usual workaround is to write a wrapper template for
'g' and static_assert (or SFINAE) that the deduced type is the same as the
expected type.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cbd77edb-084d-45ab-9a1f-01a0aaec1788%40isocpp.org
..

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4WE4ktXyob5MaWmczC46dDJyVNks%2BnJSs5QZ7xT-U2yMw%40mail.gmail.com.

--001a114407a23b9744053da1a15f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">But it is perfectly doable on the call site only, so works f=
or nontemplates. Sfinae, concepts etc require templates, no?</p>
<p dir=3D"ltr">What would you guys think about templates that restrict only=
 variety of call sites using concepts, but that keep the function body clea=
r of the argument type (and the parameter has to be fixed nontemplated type=
). Then separate compilation should still work.</p>
<p dir=3D"ltr">Am 29.09.2016 10:38 schrieb &quot;Giovanni Piero Deretta&quo=
t; &lt;<a href=3D"mailto:gpderetta@gmail.com">gpderetta@gmail.com</a>&gt;:<=
br>
&gt;<br>
&gt; On Thursday, September 29, 2016 at 5:46:06 AM UTC+1, Andrew Tomazos wr=
ote:<br>
&gt;&gt;<br>
&gt;&gt; A colleague suggested the following idea today:<br>
&gt;&gt;<br>
&gt; [snip] <br>
&gt;&gt;<br>
&gt;&gt; explicit as a decl-specifier on a function parameter indicates tha=
t standard and user-defined conversions should be suppressed on an argument=
 to that parameter.=C2=A0 This would make, for example, the following ill-f=
ormed:<br>
&gt;&gt;<br>
&gt; [snip] <br>
&gt;&gt;<br>
&gt;&gt; It would also be useful in overload resolution as the explicit ver=
sion wouldn&#39;t be considered except for an exact match on the type.<br>
&gt;&gt;<br>
&gt;&gt; Anyone find this interesting?<br>
&gt;&gt;<br>
&gt;<br>
&gt; The idea is interesting, although I&#39;m not sure that it is worth a =
language feature. The usual workaround is to write a wrapper template for &=
#39;g&#39; and static_assert (or SFINAE) that the deduced type is the same =
as the expected type.<br>
&gt;<br>
&gt; =C2=A0<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/cbd77edb-084d-45ab-9a1f-01a0aaec=
1788%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/cbd77edb-084d-45ab-9a1f-01a0aaec1788%40isocpp.org</a>.<br></p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4WE4ktXyob5MaWmczC46dDJyVNks%2B=
nJSs5QZ7xT-U2yMw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4WE4ktXyo=
b5MaWmczC46dDJyVNks%2BnJSs5QZ7xT-U2yMw%40mail.gmail.com</a>.<br />

--001a114407a23b9744053da1a15f--

.

On 29.09.2016 06:46, Andrew Tomazos wrote:
> A colleague suggested the following idea today:
>
> void f(explicit T x);
>
> explicit as a decl-specifier on a function parameter indicates that
> standard and user-defined conversions should be suppressed on an
> argument to that parameter.  This would make, for example, the following
> ill-formed:
>
>    void g(explicit int x);
>
>    double d =3D 42.0;
>
>    int main() {
>      g(d); // ERROR: d is not an int
>    }
>
> It would also be useful in overload resolution as the explicit version
> wouldn't be considered except for an exact match on the type.
>
> Anyone find this interesting?

Use the following:

```
void g(int x);

=E2=80=A6 // any other overload you might want

template <typename T>
void g(T) =3D delete; // delete everything else
```

Now `g(42.0)` yields a "use of deleted function" error.
Even works with SFINAE.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6e39826a-306a-79f8-86cc-562b293f3b8b%40gmail.com=
..

.

------=_Part_372_495818501.1475155412787
Content-Type: multipart/alternative;
 boundary="----=_Part_373_1312749149.1475155412787"

------=_Part_373_1312749149.1475155412787
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, September 29, 2016 at 7:12:27 AM UTC-4, Jonathan M=C3=BCller w=
rote:
>
> On 29.09.2016 06:46, Andrew Tomazos wrote:=20
> > A colleague suggested the following idea today:=20
> >=20
> > void f(explicit T x);=20
> >=20
> > explicit as a decl-specifier on a function parameter indicates that=20
> > standard and user-defined conversions should be suppressed on an=20
> > argument to that parameter.  This would make, for example, the followin=
g=20
> > ill-formed:=20
> >=20
> >    void g(explicit int x);=20
> >=20
> >    double d =3D 42.0;=20
> >=20
> >    int main() {=20
> >      g(d); // ERROR: d is not an int=20
> >    }=20
> >=20
> > It would also be useful in overload resolution as the explicit version=
=20
> > wouldn't be considered except for an exact match on the type.=20
> >=20
> > Anyone find this interesting?=20
>
> Use the following:=20
>
> ```=20
> void g(int x);=20
>
> =E2=80=A6 // any other overload you might want=20
>
> template <typename T>=20
> void g(T) =3D delete; // delete everything else=20
> ```=20
>
> Now `g(42.0)` yields a "use of deleted function" error.=20
> Even works with SFINAE.=20
>

Because that's many times more obtuse as to what's going on than using=20
`explicit` in the parameter list. Even the error message is misleading,=20
since now it seems to the user like they tried to call the wrong function,=
=20
instead of accidentally invoking an implicit conversion.

Also, you now have to keep both functions in sync with one another. If you=
=20
change the parameters on the main function, you have to change them on the=
=20
deleted template too.

`boost::noncopyable` was a perfectly functional solution to making=20
uncopyable types. But we added `=3D delete` syntax anyway. Why? Because it'=
s=20
more clear to the user what's going on (yes, there are other benefits, but=
=20
that was always one of the primary justifications for it). The same goes=20
here.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/d16e1dd4-82c6-426f-a849-3bb07c111007%40isocpp.or=
g.

------=_Part_373_1312749149.1475155412787
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, September 29, 2016 at 7:12:27 AM UTC-4, Jonat=
han M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 29.09=
..2016 06:46, Andrew Tomazos wrote:
<br>&gt; A colleague suggested the following idea today:
<br>&gt;
<br>&gt; void f(explicit T x);
<br>&gt;
<br>&gt; explicit as a decl-specifier on a function parameter indicates tha=
t
<br>&gt; standard and user-defined conversions should be suppressed on an
<br>&gt; argument to that parameter. =C2=A0This would make, for example, th=
e following
<br>&gt; ill-formed:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0void g(explicit int x);
<br>&gt;
<br>&gt; =C2=A0 =C2=A0double d =3D 42.0;
<br>&gt;
<br>&gt; =C2=A0 =C2=A0int main() {
<br>&gt; =C2=A0 =C2=A0 =C2=A0g(d); // ERROR: d is not an int
<br>&gt; =C2=A0 =C2=A0}
<br>&gt;
<br>&gt; It would also be useful in overload resolution as the explicit ver=
sion
<br>&gt; wouldn&#39;t be considered except for an exact match on the type.
<br>&gt;
<br>&gt; Anyone find this interesting?
<br>
<br>Use the following:
<br>
<br>```
<br>void g(int x);
<br>
<br>=E2=80=A6 // any other overload you might want
<br>
<br>template &lt;typename T&gt;
<br>void g(T) =3D delete; // delete everything else
<br>```
<br>
<br>Now `g(42.0)` yields a &quot;use of deleted function&quot; error.
<br>Even works with SFINAE.
<br></blockquote><div><br>Because that&#39;s many times more obtuse as to w=
hat&#39;s going on than using `explicit` in the parameter list. Even the er=
ror message is misleading, since now it seems to the user like they tried t=
o call the wrong function, instead of accidentally invoking an implicit con=
version.<br><br>Also, you now have to keep both functions in sync with one =
another. If you change the parameters on the main function, you have to cha=
nge them on the deleted template too.<br><br>`boost::noncopyable` was a per=
fectly functional solution to making uncopyable types. But we added `=3D de=
lete` syntax anyway. Why? Because it&#39;s more clear to the user what&#39;=
s going on (yes, there are other benefits, but that was always one of the p=
rimary justifications for it). The same goes here.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d16e1dd4-82c6-426f-a849-3bb07c111007%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d16e1dd4-82c6-426f-a849-3bb07c111007=
%40isocpp.org</a>.<br />

------=_Part_373_1312749149.1475155412787--

------=_Part_372_495818501.1475155412787--

.

--001a114fdde2e07d52053da583c1
Content-Type: text/plain; charset=UTF-8

On Sep 29, 2016 15:23, "Nicol Bolas" <jmckesson@gmail.com> wrote:
> Because that's many times more obtuse as to what's going on than using
`explicit` in the parameter list. Even the error message is misleading,
since now it seems to the user like they tried to call the wrong function,
instead of accidentally invoking an implicit conversion.

I know. I'm in favor of this proposal ad well.

I just wanted to give the OP a relatively easy solution compared to the
SFINAE stuff given in the other responses. It wasn't about his language
idea in any way.

BTW: I really want a `= delete("message")` to give more information in the
error message.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZ0OMziMw%3DTOEEQ040SrSiZj5pgYw_qSfbXPKkpzKzqVw%40mail.gmail.com.

--001a114fdde2e07d52053da583c1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On Sep 29, 2016 15:23, &quot;Nicol Bolas&quot; &lt;<a href=
=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; Because that&#39;s many times more obtuse as to what&#39;s going on th=
an using `explicit` in the parameter list. Even the error message is mislea=
ding, since now it seems to the user like they tried to call the wrong func=
tion, instead of accidentally invoking an implicit conversion.</p>
<p dir=3D"ltr">I know. I&#39;m in favor of this proposal ad well.</p>
<p dir=3D"ltr">I just wanted to give the OP a relatively easy solution comp=
ared to the SFINAE stuff given in the other responses. It wasn&#39;t about =
his language idea in any way.</p>
<p dir=3D"ltr">BTW: I really want a `=3D delete(&quot;message&quot;)` to gi=
ve more information in the error message.<br>
</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJZ0OMziMw%3DTOEEQ040SrSiZj5pgYw=
_qSfbXPKkpzKzqVw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJZ0OMziMw=
%3DTOEEQ040SrSiZj5pgYw_qSfbXPKkpzKzqVw%40mail.gmail.com</a>.<br />

--001a114fdde2e07d52053da583c1--

.

On 29 September 2016 at 16:23, Nicol Bolas <jmckesson@gmail.com> wrote:
> `boost::noncopyable` was a perfectly functional solution to making
> uncopyable types. But we added `= delete` syntax anyway. Why? Because it's
> more clear to the user what's going on (yes, there are other benefits, but
> that was always one of the primary justifications for it). The same goes
> here.


The apparent difference is that there was fairly little question on
whether making types
noncopyable is common, whereas the need for a function parameter that
doesn't do conversions
doesn't enjoy such evidence of being so obviously common.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUa3WDytMfiPTaTYQLq7MdRn7Znp1nwWQZvrsMibAS%3DE3g%40mail.gmail.com.

.

------=_Part_628_1308756246.1475176213501
Content-Type: multipart/alternative;
 boundary="----=_Part_629_1292065337.1475176213502"

------=_Part_629_1292065337.1475176213502
Content-Type: text/plain; charset=UTF-8

On Thursday, September 29, 2016 at 10:27:35 AM UTC+2, Ville Voutilainen
wrote:
>
> On 29 September 2016 at 07:46, Andrew Tomazos <andrew...@gmail.com
> <javascript:>> wrote:
> > A colleague suggested the following idea today:
> >
> > void f(explicit T x);
> >
> > explicit as a decl-specifier on a function parameter indicates that
> standard
> > and user-defined conversions should be suppressed on an argument to that
> > parameter.  This would make, for example, the following ill-formed:
> >
> >    void g(explicit int x);
> >
> >    double d = 42.0;
> >
> >    int main() {
> >      g(d); // ERROR: d is not an int
> >    }
> >
> > It would also be useful in overload resolution as the explicit version
> > wouldn't be considered except for an exact match on the type.
> >
> > Anyone find this interesting?
>
>
> The idea isn't new, but I'm not sure whether there's ever been an
> actual proposal for it. Why should it be a language
> feature? Why not just write an explicit-wrapper as a library facility(*)?
>

Quick hack that uses the tuple-trick with conditionally explicit
constructor (depending on whether the received type is identical to the
emitted type, and an implicit conversion operator to emit the wanted type:


#include <iostream>
#include <type_traits>

template<class T>
class as_explicit
{
    T t;
public:
    template<class U, std::enable_if_t<std::is_same<U, T>{}>...>
    /* implicit */ as_explicit(U&& u) : t{std::forward<U>(u)} {}

    template<class U, std::enable_if_t<!std::is_same<U, T>{}>...>
    explicit as_explicit(U&& u) : t{std::forward<U>(u)} {}

    /* implicit */ operator T() const { return t; }
};

void fun(as_explicit<int> t) { std::cout << t << '\n'; }
void gun(as_explicit<double> t) { std::cout << t << '\n'; }

int main()
{
    fun(1);     // OK
    fun(1L);    // ERROR
    fun(1.0);   // ERROR

    gun(1.0);   // OK
    gun(1.0f);  // ERROR
    gun(1);     // ERROR
}

http://coliru.stacked-crooked.com/a/6d1493d5bdc555ca

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cda5952a-0b6a-444c-a708-2720b42ee98e%40isocpp.org.

------=_Part_629_1292065337.1475176213502
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, September 29, 2016 at 10:27:35 AM UTC+2, Vill=
e Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 29 Sept=
ember 2016 at 07:46, Andrew Tomazos &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"aUmVFW6OBQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">andrew...@gmail.com</a>&gt; wrote:
<br>&gt; A colleague suggested the following idea today:
<br>&gt;
<br>&gt; void f(explicit T x);
<br>&gt;
<br>&gt; explicit as a decl-specifier on a function parameter indicates tha=
t standard
<br>&gt; and user-defined conversions should be suppressed on an argument t=
o that
<br>&gt; parameter. =C2=A0This would make, for example, the following ill-f=
ormed:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0void g(explicit int x);
<br>&gt;
<br>&gt; =C2=A0 =C2=A0double d =3D 42.0;
<br>&gt;
<br>&gt; =C2=A0 =C2=A0int main() {
<br>&gt; =C2=A0 =C2=A0 =C2=A0g(d); // ERROR: d is not an int
<br>&gt; =C2=A0 =C2=A0}
<br>&gt;
<br>&gt; It would also be useful in overload resolution as the explicit ver=
sion
<br>&gt; wouldn&#39;t be considered except for an exact match on the type.
<br>&gt;
<br>&gt; Anyone find this interesting?
<br>
<br>
<br>The idea isn&#39;t new, but I&#39;m not sure whether there&#39;s ever b=
een an
<br>actual proposal for it. Why should it be a language
<br>feature? Why not just write an explicit-wrapper as a library facility(*=
)?
<br></blockquote><div><br></div><div>Quick hack that uses the tuple-trick w=
ith conditionally explicit constructor (depending on whether the received t=
ype is identical to the emitted type, and an implicit conversion operator t=
o emit the wanted type:</div><div><br></div><div><br></div><div><font face=
=3D"courier new, monospace">#include &lt;iostream&gt;</font></div><div><fon=
t face=3D"courier new, monospace">#include &lt;type_traits&gt;</font></div>=
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">template&lt;class T&gt;</font></div><div><font =
face=3D"courier new, monospace">class as_explicit</font></div><div><font fa=
ce=3D"courier new, monospace">{</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 T t;</font></div><div><font face=3D"courier new, =
monospace">public: =C2=A0 =C2=A0</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 template&lt;class U, std::enable_if_t&lt;std::is=
_same&lt;U, T&gt;{}&gt;...&gt;</font></div><div><font face=3D"courier new, =
monospace">=C2=A0 =C2=A0 /* implicit */ as_explicit(U&amp;&amp; u) : t{std:=
:forward&lt;U&gt;(u)} {}</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 template&lt;class U, std::enable_if_t&lt;!std::is_same&l=
t;U, T&gt;{}&gt;...&gt;</font></div><div><font face=3D"courier new, monospa=
ce">=C2=A0 =C2=A0 explicit as_explicit(U&amp;&amp; u) : t{std::forward&lt;U=
&gt;(u)} {}</font></div><div><font face=3D"courier new, monospace"><br></fo=
nt></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 /* implic=
it */ operator T() const { return t; }</font></div><div><font face=3D"couri=
er new, monospace">};</font></div><div><font face=3D"courier new, monospace=
"><br></font></div><div><font face=3D"courier new, monospace">void fun(as_e=
xplicit&lt;int&gt; t) { std::cout &lt;&lt; t &lt;&lt; &#39;\n&#39;; }</font=
></div><div><font face=3D"courier new, monospace">void gun(as_explicit&lt;d=
ouble&gt; t) { std::cout &lt;&lt; t &lt;&lt; &#39;\n&#39;; }</font></div><d=
iv><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">int main()</font></div><div><font face=3D"couri=
er new, monospace">{</font></div><div><font face=3D"courier new, monospace"=
>=C2=A0 =C2=A0 fun(1); =C2=A0 =C2=A0 // OK</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 fun(1L); =C2=A0 =C2=A0// ERROR</font><=
/div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 fun(1.0); =C2=
=A0 // ERROR</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0=C2=A0</font></div><div><font face=3D"courier new, monospace">=C2=A0 =
=C2=A0 gun(1.0); =C2=A0 // OK</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 =C2=A0 gun(1.0f); =C2=A0// ERROR</font></div><div><font fa=
ce=3D"courier new, monospace">=C2=A0 =C2=A0 gun(1); =C2=A0 =C2=A0 // ERROR<=
/font></div><div><font face=3D"courier new, monospace">}</font></div><div><=
br></div><div>http://coliru.stacked-crooked.com/a/6d1493d5bdc555ca=C2=A0</d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cda5952a-0b6a-444c-a708-2720b42ee98e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cda5952a-0b6a-444c-a708-2720b42ee98e=
%40isocpp.org</a>.<br />

------=_Part_629_1292065337.1475176213502--

------=_Part_628_1308756246.1475176213501--

.

On quinta-feira, 29 de setembro de 2016 15:32:54 PDT Jonathan M=C3=BCller w=
rote:
> BTW: I really want a `=3D delete("message")` to give more information in =
the
> error message.

Meanwhile:

struct QYouForgotToDeclareStreamingOperators;
template <typename T>
QYouForgotToDeclareStreamingOperators operator<<(QDataStream &, T) =3D dele=
te;


--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/4863391.Ol1Cm86DmJ%40tjmaciei-mobl1.

.

------=_Part_1143_59495438.1475189818767
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, 29 September 2016 22:14:58 UTC+1, Thiago Macieira wrote:
>
> On quinta-feira, 29 de setembro de 2016 15:32:54 PDT Jonathan M=C3=BCller=
=20
> wrote:=20
> > BTW: I really want a `=3D delete("message")` to give more information i=
n=20
> the=20
> > error message.=20
>
> Meanwhile:=20
>
> struct QYouForgotToDeclareStreamingOperators;=20
> template <typename T>=20
> QYouForgotToDeclareStreamingOperators operator<<(QDataStream &, T) =3D=20
> delete;=20
>

For DRY and to (hopefully) reduce confusion you can use a=20
declaration-scoped forward elaborated-type-specifier:

template <typename T>=20
class QYouForgotToDeclareStreamingOperators operator<<(QDataStream &, T) =
=3D=20
delete;=20

It's still a hack compared to a =3D delete("message") though.

--=20


This e-mail together with any attachments (the "Message") is confidential=
=20
and may contain privileged information. If you are not the intended=20
recipient or if you have received this e-mail in error, please notify the=
=20
sender immediately and permanently delete this Message from your system.=20
 Do not copy, disclose or distribute the information contained in this=20
Message.

=20

Maven Investment Partners Ltd (No. 07511928), Maven Derivatives Ltd (No.=20
07511840) , MVN Asset Management Limited (No. 09659116), Maven Europe Ltd=
=20
(No. 08966593) & Maven Securities Holding Ltd (No. 07505438) are registered=
=20
as companies in England and Wales and their registered address is Level 3,=
=20
6 Bevis Marks, London EC3A 7BA, United Kingdom. The companies=E2=80=99 VAT =
No. is=20
135539016. Only Maven Derivatives Ltd and MVN Asset Management Limited are=
=20
authorised by the Financial Conduct Authority (Maven Derivatives Ltd FRN:=
=20
607267, MVN Asset Management Limited FRN: 714429)

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fe4949cb-8812-4d55-8a6f-a65c52b66c90%40isocpp.or=
g.

------=_Part_1143_59495438.1475189818767
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, 29 September 2016 22:14:58 UTC+1, Thiago Maci=
eira  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quinta-feira, 2=
9 de setembro de 2016 15:32:54 PDT Jonathan M=C3=BCller wrote:
<br>&gt; BTW: I really want a `=3D delete(&quot;message&quot;)` to give mor=
e information in the
<br>&gt; error message.
<br>
<br>Meanwhile:
<br>
<br>struct QYouForgotToDeclareStreamingOp<wbr>erators;
<br>template &lt;typename T&gt;
<br>QYouForgotToDeclareStreamingOp<wbr>erators operator&lt;&lt;(QDataStream=
 &amp;, T) =3D delete;
<br></blockquote><div><br></div><div>For DRY and to (hopefully) reduce conf=
usion you can use a declaration-scoped forward elaborated-type-specifier:</=
div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px solid rg=
b(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> <br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Q=
YouForgotToDeclareStreamingOperators</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">operator</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;&lt;(</span><span style=3D"color: #606;" class=3D"styled=
-by-prettify">QDataStream</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&amp;,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">delete</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> <br></span></div></code></div><div><br>It&#39;s st=
ill a hack compared to a =3D delete(&quot;message&quot;) though.</div></div=
>
<br>
<p><font color=3D"#222222" face=3D"Arial, sans-serif"><span style=3D"font-s=
ize:13px">This e-mail together with any attachments (the &quot;Message&quot=
;) is confidential and may contain privileged information. If you are not t=
he intended recipient or if you have received this e-mail in error, please =
notify the sender immediately and permanently delete this Message from your=
 system. =C2=A0Do not copy, disclose or distribute the information containe=
d in this Message.</span></font></p><p><font color=3D"#222222" face=3D"Aria=
l, sans-serif"><span style=3D"font-size:13px">=C2=A0</span></font></p><p><f=
ont color=3D"#222222" face=3D"Arial, sans-serif"><span style=3D"font-size:1=
3px">Maven Investment Partners Ltd (No. 07511928), Maven Derivatives Ltd (N=
o. 07511840) , MVN Asset Management Limited (No. 09659116), Maven Europe Lt=
d (No. 08966593) &amp; Maven Securities Holding Ltd (No. 07505438) are regi=
stered as companies in England and Wales and their registered address is Le=
vel 3, 6 Bevis Marks, London EC3A 7BA, United Kingdom. The companies=E2=80=
=99 VAT No. is 135539016. Only Maven Derivatives Ltd and MVN Asset Manageme=
nt Limited are authorised by the Financial Conduct Authority (Maven Derivat=
ives Ltd FRN: 607267, MVN Asset Management Limited FRN: 714429)</span></fon=
t></p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fe4949cb-8812-4d55-8a6f-a65c52b66c90%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fe4949cb-8812-4d55-8a6f-a65c52b66c90=
%40isocpp.org</a>.<br />

------=_Part_1143_59495438.1475189818767--

.

--001a114407a2f6baee053db641c8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Why deletion instead of putting a static_assert into the operators function
body: "you forgot to define operator for T". The compiler always shows what
type T is, so this is a better errormessage.

Am 29.09.2016 23:14 schrieb "Thiago Macieira" <thiago@macieira.org>:
>
> On quinta-feira, 29 de setembro de 2016 15:32:54 PDT Jonathan M=C3=BCller
wrote:
> > BTW: I really want a `=3D delete("message")` to give more information i=
n
the
> > error message.
>
> Meanwhile:
>
> struct QYouForgotToDeclareStreamingOperators;
> template <typename T>
> QYouForgotToDeclareStreamingOperators operator<<(QDataStream &, T) =3D
delete;
>
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4863391.Ol1Cm8=
6DmJ%40tjmaciei-mobl1
..

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANu6V4XkUn9%3DT0OY352qTzq75oL%3DWLddKvNNpaZa1b5=
ELZmEnw%40mail.gmail.com.

--001a114407a2f6baee053db641c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Why deletion instead of putting a static_assert into the ope=
rators function body: &quot;you forgot to define operator for T&quot;. The =
compiler always shows what type T is, so this is a better errormessage.<br>=
</p>
<p dir=3D"ltr">Am 29.09.2016 23:14 schrieb &quot;Thiago Macieira&quot; &lt;=
<a href=3D"mailto:thiago@macieira.org">thiago@macieira.org</a>&gt;:<br>
&gt;<br>
&gt; On quinta-feira, 29 de setembro de 2016 15:32:54 PDT Jonathan M=C3=BCl=
ler wrote:<br>
&gt; &gt; BTW: I really want a `=3D delete(&quot;message&quot;)` to give mo=
re information in the<br>
&gt; &gt; error message.<br>
&gt;<br>
&gt; Meanwhile:<br>
&gt;<br>
&gt; struct QYouForgotToDeclareStreamingOperators;<br>
&gt; template &lt;typename T&gt;<br>
&gt; QYouForgotToDeclareStreamingOperators operator&lt;&lt;(QDataStream &am=
p;, T) =3D delete;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info">macieir=
a.info</a> - thiago (AT) <a href=3D"http://kde.org">kde.org</a><br>
&gt; =C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<=
br>
&gt;<br>
&gt; --<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/4863391.Ol1Cm86DmJ%40tjmaciei-mo=
bl1">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4863391.O=
l1Cm86DmJ%40tjmaciei-mobl1</a>.<br></p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4XkUn9%3DT0OY352qTzq75oL%3DWLdd=
KvNNpaZa1b5ELZmEnw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4XkUn9%=
3DT0OY352qTzq75oL%3DWLddKvNNpaZa1b5ELZmEnw%40mail.gmail.com</a>.<br />

--001a114407a2f6baee053db641c8--

.

--001a1140300ca5c086053db65d3e
Content-Type: text/plain; charset=UTF-8

On Sep 30, 2016 11:31, "'Johannes Schaub' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
>
> Why deletion instead of putting a static_assert into the operators
function body: "you forgot to define operator for T". The compiler always
shows what type T is, so this is a better errormessage.

While this is much nicer, it prevents SFINAE to check whether something
provides the function. Because it always does - it just must not be used.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbHoANR6h78KGnL0wonj5YregPordRjHB4txvNn1e4FOw%40mail.gmail.com.

--001a1140300ca5c086053db65d3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On Sep 30, 2016 11:31, &quot;&#39;Johannes Schaub&#39; via I=
SO C++ Standard - Future Proposals&quot; &lt;<a href=3D"mailto:std-proposal=
s@isocpp.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Why deletion instead of putting a static_assert into the operators fun=
ction body: &quot;you forgot to define operator for T&quot;. The compiler a=
lways shows what type T is, so this is a better errormessage.</p>
<p dir=3D"ltr">While this is much nicer, it prevents SFINAE to check whethe=
r something provides the function. Because it always does - it just must no=
t be used.</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAEddoJbHoANR6h78KGnL0wonj5YregPordRj=
HB4txvNn1e4FOw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbHoANR6h78=
KGnL0wonj5YregPordRjHB4txvNn1e4FOw%40mail.gmail.com</a>.<br />

--001a1140300ca5c086053db65d3e--

.

--001a1141e6baccdd15053db67461
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Good point. Perhaps add a template parameter like

   typename triggers_static_assert<T>::type =3D 0

Am 30.09.2016 11:39 schrieb "Jonathan M=C3=BCller" <jonathanmueller.dev@gma=
il.com
>:
>
> On Sep 30, 2016 11:31, "'Johannes Schaub' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
> >
> > Why deletion instead of putting a static_assert into the operators
function body: "you forgot to define operator for T". The compiler always
shows what type T is, so this is a better errormessage.
>
> While this is much nicer, it prevents SFINAE to check whether something
provides the function. Because it always does - it just must not be used.
>
> --
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbHoANR6=
h78KGnL0wonj5YregPordRjHB4txvNn1e4FOw%40mail.gmail.com
..

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANu6V4WjpLi3%2Bqr2WacMB4bX-RCpunoaYj7nUMfS1Ux1t=
oo3jQ%40mail.gmail.com.

--001a1141e6baccdd15053db67461
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Good point. Perhaps add a template parameter like</p>
<p dir=3D"ltr">=C2=A0=C2=A0 typename triggers_static_assert&lt;T&gt;::type =
=3D 0</p>
<p dir=3D"ltr">Am 30.09.2016 11:39 schrieb &quot;Jonathan M=C3=BCller&quot;=
 &lt;<a href=3D"mailto:jonathanmueller.dev@gmail.com">jonathanmueller.dev@g=
mail.com</a>&gt;:<br>
&gt;<br>
&gt; On Sep 30, 2016 11:31, &quot;&#39;Johannes Schaub&#39; via ISO C++ Sta=
ndard - Future Proposals&quot; &lt;<a href=3D"mailto:std-proposals@isocpp.o=
rg">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; Why deletion instead of putting a static_assert into the operator=
s function body: &quot;you forgot to define operator for T&quot;. The compi=
ler always shows what type T is, so this is a better errormessage.<br>
&gt;<br>
&gt; While this is much nicer, it prevents SFINAE to check whether somethin=
g provides the function. Because it always does - it just must not be used.=
<br>
&gt;<br>
&gt; -- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbHoANR6h78KGnL0wonj5YregP=
ordRjHB4txvNn1e4FOw%40mail.gmail.com">https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAEddoJbHoANR6h78KGnL0wonj5YregPordRjHB4txvNn1e4FOw=
%40mail.gmail.com</a>.<br>
</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4WjpLi3%2Bqr2WacMB4bX-RCpunoaYj=
7nUMfS1Ux1too3jQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4WjpLi3%2=
Bqr2WacMB4bX-RCpunoaYj7nUMfS1Ux1too3jQ%40mail.gmail.com</a>.<br />

--001a1141e6baccdd15053db67461--

.

--001a1141e6bac1a117053db67af3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I am sorry.. This is not my morning :D That would be a hard error aswell...
Well, I guess we can't otherwise put the static_assert into the immediate
context directly, so it's not going to work :/

Am 30.09.2016 11:45 schrieb "Johannes Schaub" <
schaub.johannes@googlemail.com>:
>
> Good point. Perhaps add a template parameter like
>
>    typename triggers_static_assert<T>::type =3D 0
>
> Am 30.09.2016 11:39 schrieb "Jonathan M=C3=BCller" <
jonathanmueller.dev@gmail.com>:
> >
> > On Sep 30, 2016 11:31, "'Johannes Schaub' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
> > >
> > > Why deletion instead of putting a static_assert into the operators
function body: "you forgot to define operator for T". The compiler always
shows what type T is, so this is a better errormessage.
> >
> > While this is much nicer, it prevents SFINAE to check whether something
provides the function. Because it always does - it just must not be used.
> >
> > --
> > You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send
an email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbHoANR6=
h78KGnL0wonj5YregPordRjHB4txvNn1e4FOw%40mail.gmail.com
..

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CANu6V4XSVofaA_K9aQQL1ROCrD-ym__jfw4%2Baekm4scJ-=
%3D%2B7BQ%40mail.gmail.com.

--001a1141e6bac1a117053db67af3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I am sorry.. This is not my morning :D That would be a hard =
error aswell... Well, I guess we can&#39;t otherwise put the static_assert =
into the immediate context directly, so it&#39;s not going to work :/</p>
<p dir=3D"ltr">Am 30.09.2016 11:45 schrieb &quot;Johannes Schaub&quot; &lt;=
<a href=3D"mailto:schaub.johannes@googlemail.com">schaub.johannes@googlemai=
l.com</a>&gt;:<br>
&gt;<br>
&gt; Good point. Perhaps add a template parameter like<br>
&gt;<br>
&gt; =C2=A0=C2=A0 typename triggers_static_assert&lt;T&gt;::type =3D 0<br>
&gt;<br>
&gt; Am 30.09.2016 11:39 schrieb &quot;Jonathan M=C3=BCller&quot; &lt;<a hr=
ef=3D"mailto:jonathanmueller.dev@gmail.com">jonathanmueller.dev@gmail.com</=
a>&gt;:<br>
&gt; &gt;<br>
&gt; &gt; On Sep 30, 2016 11:31, &quot;&#39;Johannes Schaub&#39; via ISO C+=
+ Standard - Future Proposals&quot; &lt;<a href=3D"mailto:std-proposals@iso=
cpp.org">std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Why deletion instead of putting a static_assert into the ope=
rators function body: &quot;you forgot to define operator for T&quot;. The =
compiler always shows what type T is, so this is a better errormessage.<br>
&gt; &gt;<br>
&gt; &gt; While this is much nicer, it prevents SFINAE to check whether som=
ething provides the function. Because it always does - it just must not be =
used.<br>
&gt; &gt;<br>
&gt; &gt; -- <br>
&gt; &gt; You received this message because you are subscribed to the Googl=
e Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; &gt; To unsubscribe from this group and stop receiving emails from it,=
 send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org"=
>std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; &gt; To post to this group, send email to <a href=3D"mailto:std-propos=
als@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; &gt; To view this discussion on the web visit <a href=3D"https://group=
s.google.com/a/isocpp.org/d/msgid/std-proposals/CAEddoJbHoANR6h78KGnL0wonj5=
YregPordRjHB4txvNn1e4FOw%40mail.gmail.com">https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/CAEddoJbHoANR6h78KGnL0wonj5YregPordRjHB4txvNn1=
e4FOw%40mail.gmail.com</a>.<br></p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANu6V4XSVofaA_K9aQQL1ROCrD-ym__jfw4%=
2Baekm4scJ-%3D%2B7BQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4XSVo=
faA_K9aQQL1ROCrD-ym__jfw4%2Baekm4scJ-%3D%2B7BQ%40mail.gmail.com</a>.<br />

--001a1141e6bac1a117053db67af3--

.

--001a11481660849c0a053db7c719
Content-Type: text/plain; charset=UTF-8

wouldn't a library solution serve the purpose?

template<typename V>
struct explicit_type {
explicit_type(V const& x) :v(x) {};
explicit_type(V &&x) :v(std::move(x)) {};
template<typename Other>
explicit explicit_type(Other&&) = delete;
explicit operator V&() { return v };
//private:
V v;
};

 void g(explicit_type<int> x);

2016-09-29 10:32 GMT+03:30 Thiago Macieira <thiago@macieira.org>:

> On quarta-feira, 28 de setembro de 2016 23:46:04 PDT Andrew Tomazos wrote:
> > A colleague suggested the following idea today:
> >
> > void f(explicit T x);
> >
> > explicit as a decl-specifier on a function parameter indicates that
> > standard and user-defined conversions should be suppressed on an argument
> > to that parameter.  This would make, for example, the following
> ill-formed:
> >
> >    void g(explicit int x);
> >
> >    double d = 42.0;
> >
> >    int main() {
> >      g(d); // ERROR: d is not an int
> >    }
> >
> > It would also be useful in overload resolution as the explicit version
> > wouldn't be considered except for an exact match on the type.
> >
> > Anyone find this interesting?
>
> Yes. It has come up recently when discussing serialisation operators. For
> example, for QDataStream, you'd write the following for a given type
> MyType:
>
>         void operator<<(QDataStream &s, const MyType &t);
>
> The problem with that is that another type that converts to MyType by
> either
> constructor, cast operator or by derivation, suddenly can also get
> serialised,
> when in reality it probably should have been a compilation error because
> the
> type in question didn't have its serialisation operator defined.
>
> A workaround for this is to use a template and make the function a template
> specialisation.
>
> PS: the issue in question turned out to be a case of those famous last
> words,
> "no one is going to derive from my type!"
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/12455530.tfTrl4VhGV%40tjmaciei-mobl1.
>



--
how am I supposed to end the twisted road of  your hair in such a dark
night??
unless the candle of your face does shed some light upon my way!!!

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dHOgiRaods8aenEwQTE0jyADHPZ4q%3DXUA-J%3DT5PbqMjPg%40mail.gmail.com.

--001a11481660849c0a053db7c719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"rtl"><div class=3D"gmail_default" style=3D"text-align:left;font=
-family:&quot;arial narrow&quot;,sans-serif;font-size:large" dir=3D"ltr">wo=
uldn&#39;t a library solution serve the purpose?</div><div class=3D"gmail_d=
efault" style=3D"text-align:left;font-family:&quot;arial narrow&quot;,sans-=
serif;font-size:large" dir=3D"ltr"><br></div><div class=3D"gmail_default" s=
tyle=3D"text-align:left;font-family:&quot;arial narrow&quot;,sans-serif;fon=
t-size:large" dir=3D"ltr"><div class=3D"gmail_default" dir=3D"ltr">template=
&lt;typename V&gt;</div><div class=3D"gmail_default" dir=3D"ltr">struct exp=
licit_type {</div><div class=3D"gmail_default" dir=3D"ltr"><span class=3D"g=
mail-Apple-tab-span" style=3D"white-space:pre"> </span>explicit_type(V cons=
t&amp; x) :v(x) {};</div><div class=3D"gmail_default" dir=3D"ltr"><span cla=
ss=3D"gmail-Apple-tab-span" style=3D"white-space:pre"> </span>explicit_type=
(V &amp;&amp;x) :v(std::move(x)) {};</div><div class=3D"gmail_default" dir=
=3D"ltr"><span class=3D"gmail-Apple-tab-span" style=3D"white-space:pre"> </=
span>template&lt;typename Other&gt;</div><div class=3D"gmail_default" dir=
=3D"ltr"><span class=3D"gmail-Apple-tab-span" style=3D"white-space:pre"> </=
span>explicit explicit_type(Other&amp;&amp;) =3D delete;</div><div class=3D=
"gmail_default" dir=3D"ltr"><span class=3D"gmail-Apple-tab-span" style=3D"w=
hite-space:pre"> </span>explicit operator V&amp;() { return v };</div><div =
class=3D"gmail_default" dir=3D"ltr">//private:</div><div class=3D"gmail_def=
ault" dir=3D"ltr"><span class=3D"gmail-Apple-tab-span" style=3D"white-space=
:pre"> </span>V v;</div><div class=3D"gmail_default" dir=3D"ltr">};</div><d=
iv><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:14p=
x">=C2=A0void g(explicit_type&lt;int&gt; x);</span><br></div></div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote"><div dir=3D"ltr">20=
16-09-29 10:32 GMT+03:30 Thiago Macieira <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&gt;</s=
pan>:</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On quarta-feira,=
 28 de setembro de 2016 23:46:04 PDT Andrew Tomazos wrote:<br>
&gt; A colleague suggested the following idea today:<br>
&gt;<br>
&gt; void f(explicit T x);<br>
&gt;<br>
&gt; explicit as a decl-specifier on a function parameter indicates that<br=
>
&gt; standard and user-defined conversions should be suppressed on an argum=
ent<br>
&gt; to that parameter.=C2=A0 This would make, for example, the following i=
ll-formed:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 void g(explicit int x);<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 double d =3D 42.0;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 int main() {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 g(d); // ERROR: d is not an int<br>
&gt;=C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; It would also be useful in overload resolution as the explicit version=
<br>
&gt; wouldn&#39;t be considered except for an exact match on the type.<br>
&gt;<br>
&gt; Anyone find this interesting?<br>
<br>
</span>Yes. It has come up recently when discussing serialisation operators=
.. For<br>
example, for QDataStream, you&#39;d write the following for a given type My=
Type:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator&lt;&lt;(QDataStream &amp;s, const=
 MyType &amp;t);<br>
<br>
The problem with that is that another type that converts to MyType by eithe=
r<br>
constructor, cast operator or by derivation, suddenly can also get serialis=
ed,<br>
when in reality it probably should have been a compilation error because th=
e<br>
type in question didn&#39;t have its serialisation operator defined.<br>
<br>
A workaround for this is to use a template and make the function a template=
<br>
specialisation.<br>
<br>
PS: the issue in question turned out to be a case of those famous last word=
s,<br>
&quot;no one is going to derive from my type!&quot;<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"noref=
errer" target=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://=
kde.org" rel=3D"noreferrer" target=3D"_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<span class=3D""><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/12455530.tfTrl4VhGV%40tjmaciei=
-mobl1" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/<w=
br>isocpp.org/d/msgid/std-<wbr>proposals/12455530.tfTrl4VhGV%<wbr>40tjmacie=
i-mobl1</a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"rtl"><d=
iv><div dir=3D"ltr">how am I supposed to end the twisted road of=C2=A0 your=
 hair in such a dark night??<br>unless the candle of your face does shed so=
me light upon my way!!!<br></div></div></div></div>
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALDL7dHOgiRaods8aenEwQTE0jyADHPZ4q%3=
DXUA-J%3DT5PbqMjPg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALDL7dHOgiRa=
ods8aenEwQTE0jyADHPZ4q%3DXUA-J%3DT5PbqMjPg%40mail.gmail.com</a>.<br />

--001a11481660849c0a053db7c719--

.

------=_Part_1799_2126410051.1475237672485
Content-Type: multipart/alternative;
 boundary="----=_Part_1800_83007693.1475237672486"

------=_Part_1800_83007693.1475237672486
Content-Type: text/plain; charset=UTF-8

The deleted ctor should *not *be *explicit *otherwise double will still be
transformed to int and stored.

In any case, I think a single ctor, enabled only for the exact type is
simpler
template <typename TT,
             typename = std::enable_if_t<std::is_same_v<T, std::decay_t<TT
>>>
   >
   Guard(TT&& v) : v(std::forward<TT>(v)) {}


But in general the library solution might suffer from slight performance
issue and code bloat.

May be an [[attribute]]  is the best option for such a niche, advanced
feature?

*Or*, may be the long awaited strong typedefs can help here?

We don't want a new type to hold/subclass the object, but a new type,
indistinguishable from the original type *except *when specified otherwise
*. *
IIRC the strong typedefs proposal had facilities to fine tune what kind of
conversions are possible.

On Friday, September 30, 2016 at 2:20:20 PM UTC+3, Farid Mehrabi wrote:
>
> wouldn't a library solution serve the purpose?
>
> template<typename V>
> struct explicit_type {
> explicit_type(V const& x) :v(x) {};
> explicit_type(V &&x) :v(std::move(x)) {};
> template<typename Other>
> explicit explicit_type(Other&&) = delete;
> explicit operator V&() { return v };
> //private:
> V v;
> };
>
>  void g(explicit_type<int> x);
>
> 2016-09-29 10:32 GMT+03:30 Thiago Macieira <thi...@macieira.org
> <javascript:>>:
>
>> On quarta-feira, 28 de setembro de 2016 23:46:04 PDT Andrew Tomazos wrote:
>> > A colleague suggested the following idea today:
>> >
>> > void f(explicit T x);
>> >
>> > explicit as a decl-specifier on a function parameter indicates that
>> > standard and user-defined conversions should be suppressed on an
>> argument
>> > to that parameter.  This would make, for example, the following
>> ill-formed:
>> >
>> >    void g(explicit int x);
>> >
>> >    double d = 42.0;
>> >
>> >    int main() {
>> >      g(d); // ERROR: d is not an int
>> >    }
>> >
>> > It would also be useful in overload resolution as the explicit version
>> > wouldn't be considered except for an exact match on the type.
>> >
>> > Anyone find this interesting?
>>
>> Yes. It has come up recently when discussing serialisation operators. For
>> example, for QDataStream, you'd write the following for a given type
>> MyType:
>>
>>         void operator<<(QDataStream &s, const MyType &t);
>>
>> The problem with that is that another type that converts to MyType by
>> either
>> constructor, cast operator or by derivation, suddenly can also get
>> serialised,
>> when in reality it probably should have been a compilation error because
>> the
>> type in question didn't have its serialisation operator defined.
>>
>> A workaround for this is to use a template and make the function a
>> template
>> specialisation.
>>
>> PS: the issue in question turned out to be a case of those famous last
>> words,
>> "no one is going to derive from my type!"
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>    Software Architect - Intel Open Source Technology Center
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12455530.tfTrl4VhGV%40tjmaciei-mobl1
>> .
>>
>
>
>
> --
> how am I supposed to end the twisted road of  your hair in such a dark
> night??
> unless the candle of your face does shed some light upon my way!!!
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2f441f29-8e96-4c95-b810-e5c55c7147cb%40isocpp.org.

------=_Part_1800_83007693.1475237672486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The deleted ctor should <i>not </i>be <b>explicit </b>othe=
rwise double will still be transformed to int and stored.<div><br></div><di=
v>In any case, I think a single ctor, enabled only for the exact type is si=
mpler=C2=A0</div><div><div class=3D"prettyprint" style=3D"background-color:=
 rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid;=
 border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><div><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> TT<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span></d=
iv><div><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e=
nable_if_t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">is_same_</span><wbr><=
span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">decay_t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>TT</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;&gt=
;&gt;</span></div><div><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> =C2=A0 =C2=A0</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&gt;</span></div><div><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> =C2=A0 =C2=A0</span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Guard</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">TT</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&am=
p;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">forward</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">TT<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">))</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{}</span></div></div></code></div><div><br=
></div><div><br></div>But in general the library solution might suffer from=
 slight performance issue and code bloat.</div><div><br></div><div>May be a=
n [[attribute]] =C2=A0is the best option for such a niche, advanced feature=
?</div><div><br></div><div><b>Or</b>, may be the long awaited strong typede=
fs can help here?=C2=A0</div><div><br></div><div>We don&#39;t want a new ty=
pe to hold/subclass the object, but a new type, indistinguishable from the =
original type=C2=A0<b>except </b>when specified otherwise<b>.=C2=A0</b>=C2=
=A0</div><div>IIRC the strong typedefs proposal had facilities to fine tune=
 what kind of conversions are possible.</div><div><br>On Friday, September =
30, 2016 at 2:20:20 PM UTC+3, Farid Mehrabi wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"rtl"><div style=3D"text-align:left;font-fam=
ily:&quot;arial narrow&quot;,sans-serif;font-size:large" dir=3D"ltr">wouldn=
&#39;t a library solution serve the purpose?</div><div style=3D"text-align:=
left;font-family:&quot;arial narrow&quot;,sans-serif;font-size:large" dir=
=3D"ltr"><br></div><div style=3D"text-align:left;font-family:&quot;arial na=
rrow&quot;,sans-serif;font-size:large" dir=3D"ltr"><div dir=3D"ltr">templat=
e&lt;typename V&gt;</div><div dir=3D"ltr">struct explicit_type {</div><div =
dir=3D"ltr"><span style=3D"white-space:pre"> </span>explicit_type(V const&a=
mp; x) :v(x) {};</div><div dir=3D"ltr"><span style=3D"white-space:pre"> </s=
pan>explicit_type(V &amp;&amp;x) :v(std::move(x)) {};</div><div dir=3D"ltr"=
><span style=3D"white-space:pre"> </span>template&lt;typename Other&gt;</di=
v><div dir=3D"ltr"><span style=3D"white-space:pre"> </span>explicit explici=
t_type(Other&amp;&amp;) =3D delete;</div><div dir=3D"ltr"><span style=3D"wh=
ite-space:pre"> </span>explicit operator V&amp;() { return v };</div><div d=
ir=3D"ltr">//private:</div><div dir=3D"ltr"><span style=3D"white-space:pre"=
> </span>V v;</div><div dir=3D"ltr">};</div><div><br></div><div><span style=
=3D"font-family:arial,sans-serif;font-size:14px">=C2=A0void g(explicit_type=
&lt;int&gt; x);</span><br></div></div></div><div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr">2016-09-29 10:32 GMT+03:30 Thiago Macieira <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"zxVJAXDmBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">thi...@macieira.org</a>&gt;</span>:</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span>On quarta-feira, 28 de setembro de 2016 23:46:04 PDT Andrew Toma=
zos wrote:<br>
&gt; A colleague suggested the following idea today:<br>
&gt;<br>
&gt; void f(explicit T x);<br>
&gt;<br>
&gt; explicit as a decl-specifier on a function parameter indicates that<br=
>
&gt; standard and user-defined conversions should be suppressed on an argum=
ent<br>
&gt; to that parameter.=C2=A0 This would make, for example, the following i=
ll-formed:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 void g(explicit int x);<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 double d =3D 42.0;<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 int main() {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 g(d); // ERROR: d is not an int<br>
&gt;=C2=A0 =C2=A0 }<br>
&gt;<br>
&gt; It would also be useful in overload resolution as the explicit version=
<br>
&gt; wouldn&#39;t be considered except for an exact match on the type.<br>
&gt;<br>
&gt; Anyone find this interesting?<br>
<br>
</span>Yes. It has come up recently when discussing serialisation operators=
.. For<br>
example, for QDataStream, you&#39;d write the following for a given type My=
Type:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 void operator&lt;&lt;(QDataStream &amp;s, const=
 MyType &amp;t);<br>
<br>
The problem with that is that another type that converts to MyType by eithe=
r<br>
constructor, cast operator or by derivation, suddenly can also get serialis=
ed,<br>
when in reality it probably should have been a compilation error because th=
e<br>
type in question didn&#39;t have its serialisation operator defined.<br>
<br>
A workaround for this is to use a template and make the function a template=
<br>
specialisation.<br>
<br>
PS: the issue in question turned out to be a case of those famous last word=
s,<br>
&quot;no one is going to derive from my type!&quot;<br>
<br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" rel=3D"nofol=
low" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;">=
macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" rel=3D"nofollow"=
 target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.google.com/ur=
l?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHGRJdo5=
_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
<span><br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
zxVJAXDmBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"zxVJAXDmBQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
</span>To view this discussion on the web visit <a href=3D"https://groups.g=
oogle.com/a/isocpp.org/d/msgid/std-proposals/12455530.tfTrl4VhGV%40tjmaciei=
-mobl1" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12455530.tfTrl=
4VhGV%40tjmaciei-mobl1&#39;;return true;" onclick=3D"this.href=3D&#39;https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12455530.tfTrl4VhGV=
%40tjmaciei-mobl1&#39;;return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/12455530.tfTrl4VhGV%<wbr>40tjmaciei-mobl1<=
/a>.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div><div di=
r=3D"rtl"><div><div dir=3D"ltr">how am I supposed to end the twisted road o=
f=C2=A0 your hair in such a dark night??<br>unless the candle of your face =
does shed some light upon my way!!!<br></div></div></div></div>
</div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2f441f29-8e96-4c95-b810-e5c55c7147cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2f441f29-8e96-4c95-b810-e5c55c7147cb=
%40isocpp.org</a>.<br />

------=_Part_1800_83007693.1475237672486--

------=_Part_1799_2126410051.1475237672485--

.