------=_Part_1152_1941065847.1443813012219
Content-Type: multipart/alternative;
 boundary="----=_Part_1153_567581249.1443813012220"

------=_Part_1153_567581249.1443813012220
Content-Type: text/plain; charset=UTF-8

Hello David,

I think applying decay to the parameters of common_type first is a good
idea (I suggested the same thing a few years ago but never did the work of
writing a paper). I think you really need to reference
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2465 which is
very similar (2460 may also be relevant).

I would just like to suggest one minor tweak: instead of applying decay,
you could apply the unary version of common_type. The difference is that
users are allowed to specialize common_type but not decay (at least until
someone proposes to change that, or until what used to be called "operator
auto", "typedef auto" or "using auto" reappears). One case where it makes a
difference is expression templates. If I specify that the "decayed" version
of expr<type,formula> is type (by specializing the unary common_type), in
some libraries I won't even need to specialize the binary version because
?: will already do the right thing. But I can understand if people think
this is not the right place to fix this.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Hello David,<br><br>I think applying decay to the paramete=
rs of common_type first is a good idea (I suggested the same thing a few ye=
ars ago but never did the work of writing a paper). I think you really need=
 to reference http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#2=
465 which is very similar (2460 may also be relevant).<br><br>I would just =
like to suggest one minor tweak: instead of applying decay, you could apply=
 the unary version of common_type. The difference is that users are allowed=
 to specialize common_type but not decay (at least until someone proposes t=
o change that, or until what used to be called &quot;operator auto&quot;, &=
quot;typedef auto&quot; or &quot;using auto&quot; reappears). One case wher=
e it makes a difference is expression templates. If I specify that the &quo=
t;decayed&quot; version of expr&lt;type,formula&gt; is type (by specializin=
g the unary common_type), in some libraries I won&#39;t even need to specia=
lize the binary version because ?: will already do the right thing. But I c=
an understand if people think this is not the right place to fix this.<br><=
/div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1153_567581249.1443813012220--
------=_Part_1152_1941065847.1443813012219--

.

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

Thanks for the defect reference. This proposal should resolve that defect.

As far as delegating to single-argument common_type, that to me feels like
working around a problem rather than addressing it. I agree that we need
something to fix the expression template + auto problem, but I do not think
that common_type is that place, as it is a much larger problem than this.

I believe that using auto was my favorite solution to that problem, so
perhaps I should dig up the discussion on the ISOCPP proposals forum and
write up a paper for 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div><div>Thanks for the defect reference. This proposal s=
hould resolve that defect.<br><br></div>As far as delegating to single-argu=
ment common_type, that to me feels like working around a problem rather tha=
n addressing it. I agree that we need something to fix the expression templ=
ate + auto problem, but I do not think that common_type is that place, as i=
t is a much larger problem than this.<br><br>I believe that using auto was =
my favorite solution to that problem, so perhaps I should dig up the discus=
sion on the ISOCPP proposals forum and write up a paper for it.<br></div></=
div>

<p></p>

-- <br />
<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+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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113d22028bb8720521278c8e--

.