Topic: auto and expression templates using attributes
Author: Till Heinzel <tillheinzel0@gmail.com>
Date: Tue, 16 Oct 2018 01:44:22 -0700 (PDT)
Raw View
------=_Part_1463_1349798002.1539679462764
Content-Type: multipart/alternative;
boundary="----=_Part_1464_1071485837.1539679462765"
------=_Part_1464_1071485837.1539679462765
Content-Type: text/plain; charset="UTF-8"
I have previously worked a lot with expression templates, and using them
together with auto is a pain - errors crop up all the time, and I ended up
wrapping most of the functionality away.
I have been looking at P0672R0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf> and I
think that sounds like a pretty good idea, but it also seems to be a quite
invasive solution. I also looked at this discussion: a C++17 library
solution to N4035, expression templates, auto and class template argument
deduction
<https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/%22expression$20template%22%7Csort:date/std-proposals/ErPSC92ERDU/cUHPa_bgAgAJ>,
which does not seem to address the problem, as it is still up to the user
to see when to use the proposed type.
So instead, I would propose adding a new attribute [[temporary_type]] that
tells the compiler to emit a warning when an object of the type is used in
a non-temporary context. I am not too certain on value categories, but I
think it would work well if this would just mean a warning when the object
is an lvalue. The user then knows to call some function, or to use a cast
or an explicit type for the assignment, whatever works in the context of
the library.
An accompanying attribute could be [[allowed_temporary_lvalue]], to
suppress the warning at the call site. This would allow using the type
warning-free within the library where it is created, and clearly express
that this is a special case, not the primary use case for this type.
While I find P0672R0 interesting, I also think it may be overkill for a
relatively niche problem. I ran into it using armadillo (linear algebra),
the Wikipedia site specifies mostly linear algebra as a use case, and a
quick google search ends up with the same thing. So on a value-effort
graph, I think P0672R0 has to much effort for too little value. Attributes
do not change the core language significantly, do not introduce new syntax
or complexities, they simply tell compilers to emit warnings under certain
conditions. That seems like a much cheaper way of getting some safety into
the use of expression templates. It does not allow the drop-in replacement
of expression templates, but I consider that a somewhat minor problem
compared to the bugs that crop up when using them in an auto-riddled,
modern-C++ world.
I am not an expert on the standard, so I would love some comments on 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2f62daa1-aeb8-4a56-af97-d622a8b9030a%40isocpp.org.
------=_Part_1464_1071485837.1539679462765
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I have previously worked a lot with expression templa=
tes, and using them together with auto is a pain - errors crop up all the t=
ime, and I ended up wrapping most of the functionality away.</div><div>I ha=
ve been looking at <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2017/p0672r0.pdf">P0672R0</a> and I think that sounds like a pretty g=
ood idea, but it also seems to be a quite invasive solution. I also looked =
at this discussion: <a href=3D"https://groups.google.com/a/isocpp.org/forum=
/#!searchin/std-proposals/%22expression$20template%22%7Csort:date/std-propo=
sals/ErPSC92ERDU/cUHPa_bgAgAJ">a C++17 library solution to N4035, expressio=
n templates, auto and class template argument deduction</a>, which does not=
seem to address the problem, as it is still up to the user to see when to =
use the proposed type. <br></div><div><br></div><div>So instead, I would pr=
opose adding a new attribute [[temporary_type]] that tells the compiler to =
emit a warning when an object of the type is used in a non-temporary contex=
t. I am not too certain on value categories, but I think it would work well=
if this would just mean a warning when the object is an lvalue. The user t=
hen knows to call some function, or to use a cast or an explicit type for t=
he assignment, whatever works in the context of the library. <br></div><div=
>An accompanying attribute could be [[allowed_temporary_lvalue]], to suppre=
ss the warning at the call site. This would allow using the type warning-fr=
ee within the library where it is created, and clearly express that this is=
a special case, not the primary use case for this type. <br></div><div><br=
></div><div>While I find P0672R0 interesting, I also think it may be overki=
ll for a relatively niche problem. I ran into it using armadillo (linear al=
gebra), the Wikipedia site specifies mostly linear algebra as a use case, a=
nd a quick google search ends up with the same thing. So on a value-effort =
graph, I think P0672R0 has to much effort for too little value. Attributes =
do not change the core language significantly, do not introduce new syntax =
or complexities, they simply tell compilers to emit warnings under certain =
conditions. That seems like a much cheaper way of getting some safety into =
the use of expression templates. It does not allow the drop-in replacement =
of expression templates, but I consider that a somewhat minor problem compa=
red to the bugs that crop up when using them in an auto-riddled, modern-C++=
world. <br></div><div><br></div><div>I am not an expert on the standard, s=
o I would love some comments on this.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/2f62daa1-aeb8-4a56-af97-d622a8b9030a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2f62daa1-aeb8-4a56-af97-d622a8b9030a=
%40isocpp.org</a>.<br />
------=_Part_1464_1071485837.1539679462765--
------=_Part_1463_1349798002.1539679462764--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Wed, 17 Oct 2018 08:08:35 -0700 (PDT)
Raw View
------=_Part_2649_270306849.1539788915173
Content-Type: multipart/alternative;
boundary="----=_Part_2650_1568904867.1539788915173"
------=_Part_2650_1568904867.1539788915173
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, October 16, 2018 at 1:44:22 AM UTC-7, Till Heinzel wrote:
>
> I have previously worked a lot with expression templates, and using them=
=20
> together with auto is a pain - errors crop up all the time, and I ended u=
p=20
> wrapping most of the functionality away.
> I have been looking at P0672R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf> and=
=20
> I think that sounds like a pretty good idea, but it also seems to be a=20
> quite invasive solution. I also looked at this discussion: a C++17=20
> library solution to N4035, expression templates, auto and class template=
=20
> argument deduction=20
> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/%2=
2expression$20template%22%7Csort:date/std-proposals/ErPSC92ERDU/cUHPa_bgAgA=
J>,=20
> which does not seem to address the problem, as it is still up to the user=
=20
> to see when to use the proposed type.=20
>
> So instead, I would propose adding a new attribute [[temporary_type]] tha=
t=20
> tells the compiler to emit a warning when an object of the type is used i=
n=20
> a non-temporary context. I am not too certain on value categories, but I=
=20
> think it would work well if this would just mean a warning when the objec=
t=20
> is an lvalue. The user then knows to call some function, or to use a cast=
=20
> or an explicit type for the assignment, whatever works in the context of=
=20
> the library.=20
> An accompanying attribute could be [[allowed_temporary_lvalue]], to=20
> suppress the warning at the call site. This would allow using the type=20
> warning-free within the library where it is created, and clearly express=
=20
> that this is a special case, not the primary use case for this type.=20
>
> While I find P0672R0 interesting, I also think it may be overkill for a=
=20
> relatively niche problem. I ran into it using armadillo (linear algebra),=
=20
> the Wikipedia site specifies mostly linear algebra as a use case, and a=
=20
> quick google search ends up with the same thing. So on a value-effort=20
> graph, I think P0672R0 has to much effort for too little value. Attribute=
s=20
> do not change the core language significantly, do not introduce new synta=
x=20
> or complexities, they simply tell compilers to emit warnings under certai=
n=20
> conditions. That seems like a much cheaper way of getting some safety int=
o=20
> the use of expression templates. It does not allow the drop-in replacemen=
t=20
> of expression templates, but I consider that a somewhat minor problem=20
> compared to the bugs that crop up when using them in an auto-riddled,=20
> modern-C++ world.=20
>
> I am not an expert on the standard, so I would love some comments on this=
..
>
(FWIW: A blog post=20
<https://quuxplusone.github.io/blog/2018/07/12/operator-auto/> I wrote back=
=20
in July on the subject.)
I am surprised that P0672R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf> does=
=20
not have any R1 in the San Diego mailing.
(1) I like P0672's approach with `using auto =3D Matrix;`.
(2) I *dislike* P0672's cavalier suggestion that
*auto* x =3D A*B;
should behave fundamentally differently from
auto f =3D [](*auto* x){ ... }
f(A*B);
in this respect. That kind of arbitrary subtlety is the bane of C++ and we=
=20
don't need more of it.
(3) I am skeptical that either P0672 or Till's suggestion would solve the=
=20
problem of
std::vector<bool> vec(100);
for (auto& elt : vec) {
elt =3D true;
}
which has been presented recently as a classic example of proxy types=20
ruining everything for everybody.
But perhaps we don't need to solve that problem; we just need to teach=20
everyone to use the correct
std::vector<bool> vec(100);
for (auto&& elt : vec) {
elt =3D true;
}
which Just Works for every type in the world, including proxy types and=20
const vectors and even ranges that return rvalues from their iterators.
(4) Till, I think your idea is possibly fruitful, but you'd have to work=20
out the corner cases =E2=80=94 ideally by making a compiler implementation =
of the=20
attribute (e.g. in Clang). What counts as an "lvalue"? What happens in the=
=20
"auto&& elt : vec" example above? What happens if I just say "const auto&=
=20
T =3D A*B;", even if I never use `T` as an lvalue? What happens if I do th=
at=20
and then use `Matrix C =3D std::move(T);` =E2=80=94 does that count as an l=
value use=20
of `T`? And so on. If you can get a Clang attribute with unit tests that=
=20
look good, then it might help programmers even if P0672 never makes any=20
more progress.
my $.02,
=E2=80=93Arthur
--=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/2bf1f2eb-04c6-4985-a86a-123b25662eff%40isocpp.or=
g.
------=_Part_2650_1568904867.1539788915173
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 16, 2018 at 1:44:22 AM UTC-7, Till Hei=
nzel 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"ltr"><d=
iv>I have previously worked a lot with expression templates, and using them=
together with auto is a pain - errors crop up all the time, and I ended up=
wrapping most of the functionality away.</div><div>I have been looking at =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.=
pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2Fdocs%2Fpapers%2F2017%2Fp0672r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFtCG3f4FMvJWXN9cyPvisJJMeFwQ';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0672r0.pdf\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNFtCG3f4FMvJWXN9cyPvisJJMeFwQ';return true;">P0672R0</a=
> and I think that sounds like a pretty good idea, but it also seems to be =
a quite invasive solution. I also looked at this discussion: <a href=3D"htt=
ps://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/%22expre=
ssion$20template%22%7Csort:date/std-proposals/ErPSC92ERDU/cUHPa_bgAgAJ" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://gro=
ups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/%22expression$20=
template%22%7Csort:date/std-proposals/ErPSC92ERDU/cUHPa_bgAgAJ';return =
true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/f=
orum/#!searchin/std-proposals/%22expression$20template%22%7Csort:date/std-p=
roposals/ErPSC92ERDU/cUHPa_bgAgAJ';return true;">a C++17 library soluti=
on to N4035, expression templates, auto and class template argument deducti=
on</a>, which does not seem to address the problem, as it is still up to th=
e user to see when to use the proposed type. <br></div><div><br></div><div>=
So instead, I would propose adding a new attribute [[temporary_type]] that =
tells the compiler to emit a warning when an object of the type is used in =
a non-temporary context. I am not too certain on value categories, but I th=
ink it would work well if this would just mean a warning when the object is=
an lvalue. The user then knows to call some function, or to use a cast or =
an explicit type for the assignment, whatever works in the context of the l=
ibrary. <br></div><div>An accompanying attribute could be [[allowed_tempora=
ry_lvalue]], to suppress the warning at the call site. This would allow usi=
ng the type warning-free within the library where it is created, and clearl=
y express that this is a special case, not the primary use case for this ty=
pe. <br></div><div><br></div><div>While I find P0672R0 interesting, I also =
think it may be overkill for a relatively niche problem. I ran into it usin=
g armadillo (linear algebra), the Wikipedia site specifies mostly linear al=
gebra as a use case, and a quick google search ends up with the same thing.=
So on a value-effort graph, I think P0672R0 has to much effort for too lit=
tle value. Attributes do not change the core language significantly, do not=
introduce new syntax or complexities, they simply tell compilers to emit w=
arnings under certain conditions. That seems like a much cheaper way of get=
ting some safety into the use of expression templates. It does not allow th=
e drop-in replacement of expression templates, but I consider that a somewh=
at minor problem compared to the bugs that crop up when using them in an au=
to-riddled, modern-C++ world. <br></div><div><br></div><div>I am not an exp=
ert on the standard, so I would love some comments on this.<br></div></div>=
</blockquote><div><br></div><div>(FWIW: A <a href=3D"https://quuxplusone.gi=
thub.io/blog/2018/07/12/operator-auto/">blog post</a> I wrote back in July =
on the subject.)</div><div>I am surprised that <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf">P0672R0</a> does not ha=
ve any R1 in the San Diego mailing.<br></div><div><br></div><div>(1) I like=
P0672's approach with `using auto =3D Matrix;`.</div><div><br></div><d=
iv>(2) I <i>dislike</i> P0672's cavalier suggestion that</div><div><br>=
</div><div>=C2=A0 =C2=A0 <b>auto</b> x =3D A*B;</div><div><br></div><div>sh=
ould behave fundamentally differently from</div><div><br></div><div>=C2=A0 =
=C2=A0 auto f =3D [](<b>auto</b> x){ ... }</div><div>=C2=A0 =C2=A0 f(A*B);<=
/div><div><br></div><div>in this respect. That kind of arbitrary subtlety i=
s the bane of C++ and we don't need more of it.</div><div><br></div><di=
v>(3) I am skeptical that either P0672 or Till's suggestion would solve=
the problem of</div><div><br></div><div>=C2=A0 =C2=A0 std::vector<bool&=
gt; vec(100);</div><div>=C2=A0 =C2=A0 for (auto& elt : vec) {</div><div=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 elt =3D true;</div><div>=C2=A0 =C2=A0 }</div><=
div><br></div><div>which has been presented recently as a classic example o=
f proxy types ruining everything for everybody.</div><div>But perhaps we do=
n't need to solve that problem; we just need to teach everyone to use t=
he correct</div><div><br></div><div><div>=C2=A0 =C2=A0 std::vector<bool&=
gt; vec(100);</div><div>=C2=A0 =C2=A0 for (auto&& elt : vec) {</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 elt =3D true;</div><div>=C2=A0 =C2=A0 }</=
div></div><div><br></div><div>which Just Works for every type in the world,=
including proxy types and const vectors and even ranges that return rvalue=
s from their iterators.</div><div><br></div><div>(4) Till, I think your ide=
a is possibly fruitful, but you'd have to work out the corner cases =E2=
=80=94 ideally by making a compiler implementation of the attribute (e.g. i=
n Clang). What counts as an "lvalue"? =C2=A0What happens in the &=
quot;auto&& elt : vec" example above? =C2=A0What happens if I =
just say "const auto& T =3D A*B;", even if I never use `T` as=
an lvalue? =C2=A0What happens if I do that and then use `Matrix C =3D std:=
:move(T);` =E2=80=94 does that count as an lvalue use of `T`? And so on. =
=C2=A0If you can get a Clang attribute with unit tests that look good, then=
it might help programmers even if P0672 never makes any more progress.</di=
v><div><br></div><div>my $.02,</div><div>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/2bf1f2eb-04c6-4985-a86a-123b25662eff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2bf1f2eb-04c6-4985-a86a-123b25662eff=
%40isocpp.org</a>.<br />
------=_Part_2650_1568904867.1539788915173--
------=_Part_2649_270306849.1539788915173--
.
Author: hubert.reinterpretcast@gmail.com
Date: Thu, 18 Oct 2018 20:12:43 -0700 (PDT)
Raw View
------=_Part_3328_1190624742.1539918763381
Content-Type: multipart/alternative;
boundary="----=_Part_3329_2126778946.1539918763381"
------=_Part_3329_2126778946.1539918763381
Content-Type: text/plain; charset="UTF-8"
On Tuesday, October 16, 2018 at 4:44:22 AM UTC-4, Till Heinzel wrote:
>
> I have previously worked a lot with expression templates, and using them
> together with auto is a pain - errors crop up all the time, and I ended up
> wrapping most of the functionality away.
> I have been looking at P0672R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.pdf> and
> I think that sounds like a pretty good idea, but it also seems to be a
> quite invasive solution. I also looked at this discussion: a C++17
> library solution to N4035, expression templates, auto and class template
> argument deduction
> <https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/%22expression$20template%22%7Csort:date/std-proposals/ErPSC92ERDU/cUHPa_bgAgAJ>,
> which does not seem to address the problem, as it is still up to the user
> to see when to use the proposed type.
>
> So instead, I would propose adding a new attribute [[temporary_type]] that
> tells the compiler to emit a warning when an object of the type is used in
> a non-temporary context. I am not too certain on value categories, but I
> think it would work well if this would just mean a warning when the object
> is an lvalue. The user then knows to call some function, or to use a cast
> or an explicit type for the assignment, whatever works in the context of
> the library.
> An accompanying attribute could be [[allowed_temporary_lvalue]], to
> suppress the warning at the call site. This would allow using the type
> warning-free within the library where it is created, and clearly express
> that this is a special case, not the primary use case for this type.
>
> While I find P0672R0 interesting, I also think it may be overkill for a
> relatively niche problem. I ran into it using armadillo (linear algebra),
> the Wikipedia site specifies mostly linear algebra as a use case, and a
> quick google search ends up with the same thing. So on a value-effort
> graph, I think P0672R0 has to much effort for too little value. Attributes
> do not change the core language significantly, do not introduce new syntax
> or complexities, they simply tell compilers to emit warnings under certain
> conditions. That seems like a much cheaper way of getting some safety into
> the use of expression templates. It does not allow the drop-in replacement
> of expression templates, but I consider that a somewhat minor problem
> compared to the bugs that crop up when using them in an auto-riddled,
> modern-C++ world.
>
I think there are a few operations that may be indicative of problem with
delayed evaluation/proxy types:
copy/move
discard (I'll vaguely throw non-dependent operator void() out there)
reference binding
A temporary bound to a reference such that the reference extends the
lifetime of the temporary is a potentially problematic case that you may
want to consider with regards to the attributes you are proposing.
>
> I am not an expert on the standard, so I would love some comments on 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/55c9a427-37c7-4a22-8e8a-8c5f00059852%40isocpp.org.
------=_Part_3329_2126778946.1539918763381
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, October 16, 2018 at 4:44:22 AM UTC-4, Till Hei=
nzel 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"ltr"><d=
iv>I have previously worked a lot with expression templates, and using them=
together with auto is a pain - errors crop up all the time, and I ended up=
wrapping most of the functionality away.</div><div>I have been looking at =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0672r0.=
pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2Fdocs%2Fpapers%2F2017%2Fp0672r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFtCG3f4FMvJWXN9cyPvisJJMeFwQ';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0672r0.pdf\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNFtCG3f4FMvJWXN9cyPvisJJMeFwQ';return true;">P0672R0</a=
> and I think that sounds like a pretty good idea, but it also seems to be =
a quite invasive solution. I also looked at this discussion: <a href=3D"htt=
ps://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/%22expre=
ssion$20template%22%7Csort:date/std-proposals/ErPSC92ERDU/cUHPa_bgAgAJ" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://gro=
ups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/%22expression$20=
template%22%7Csort:date/std-proposals/ErPSC92ERDU/cUHPa_bgAgAJ';return =
true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/f=
orum/#!searchin/std-proposals/%22expression$20template%22%7Csort:date/std-p=
roposals/ErPSC92ERDU/cUHPa_bgAgAJ';return true;">a C++17 library soluti=
on to N4035, expression templates, auto and class template argument deducti=
on</a>, which does not seem to address the problem, as it is still up to th=
e user to see when to use the proposed type. <br></div><div><br></div><div>=
So instead, I would propose adding a new attribute [[temporary_type]] that =
tells the compiler to emit a warning when an object of the type is used in =
a non-temporary context. I am not too certain on value categories, but I th=
ink it would work well if this would just mean a warning when the object is=
an lvalue. The user then knows to call some function, or to use a cast or =
an explicit type for the assignment, whatever works in the context of the l=
ibrary. <br></div><div>An accompanying attribute could be [[allowed_tempora=
ry_lvalue]], to suppress the warning at the call site. This would allow usi=
ng the type warning-free within the library where it is created, and clearl=
y express that this is a special case, not the primary use case for this ty=
pe. <br></div><div><br></div><div>While I find P0672R0 interesting, I also =
think it may be overkill for a relatively niche problem. I ran into it usin=
g armadillo (linear algebra), the Wikipedia site specifies mostly linear al=
gebra as a use case, and a quick google search ends up with the same thing.=
So on a value-effort graph, I think P0672R0 has to much effort for too lit=
tle value. Attributes do not change the core language significantly, do not=
introduce new syntax or complexities, they simply tell compilers to emit w=
arnings under certain conditions. That seems like a much cheaper way of get=
ting some safety into the use of expression templates. It does not allow th=
e drop-in replacement of expression templates, but I consider that a somewh=
at minor problem compared to the bugs that crop up when using them in an au=
to-riddled, modern-C++ world. <br></div></div></blockquote><div><div>I thin=
k there are a few operations that may be indicative of problem with delayed=
evaluation/proxy types:<br></div><div>copy/move<br></div><div>discard (I&#=
39;ll vaguely throw non-dependent <span style=3D"font-family: courier new, =
monospace;">operator void()</span> out there)<br></div><div>reference bindi=
ng</div><div><br></div><div>A temporary bound to a reference such that the =
reference extends the lifetime of the temporary is a potentially problemati=
c case that you may want to consider with regards to the attributes you are=
proposing.<br></div></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div></div><div><br></div><div>I am not an e=
xpert on the standard, so I would love some comments on this.<br></div></di=
v></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/55c9a427-37c7-4a22-8e8a-8c5f00059852%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55c9a427-37c7-4a22-8e8a-8c5f00059852=
%40isocpp.org</a>.<br />
------=_Part_3329_2126778946.1539918763381--
------=_Part_3328_1190624742.1539918763381--
.