------=_Part_3090_80176470.1452727377304
Content-Type: multipart/alternative;
boundary="----=_Part_3091_528198320.1452727377304"
------=_Part_3091_528198320.1452727377304
Content-Type: text/plain; charset=UTF-8
I'd like to propose the variable-equivalent of auto return-type deduction.
Consider the following motivating example:
void do_something() {
auto x; // default construct
if (some_flag()) {
do_something_else();
and_some_other_thing();
x = some(complicated(), expression() + here(whose(type_is(), not
obvious())) / that(), I_dont_want_to_repeat());
}
and_another_thing();
std::cout << x;
}
C++ doesn't allow the usage of auto in this manner. The best workaround I
can think of would involve using decltype and repeating
"some(complicated(), expression() + here(whose(type_is(), not obvious())) /
that(), I_dont_want_to_repeat())" on the line where x is declared. As the
expression indicates, this need to repeat might go against the programmer's
wishes.
In principle, the programmer's wishes can be respected here. We can follow
the same rules as return type deduction. If x is reassigned later with a
different type, the code should simply fail to compile.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3091_528198320.1452727377304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'd like to propose the variable-equivalent of auto re=
turn-type deduction.<br><br>Consider the following motivating example:<br><=
br>void do_something() {<br>=C2=A0 auto x;=C2=A0 // default construct<br>=
=C2=A0 if (some_flag()) {<br>=C2=A0=C2=A0=C2=A0 do_something_else();<br>=C2=
=A0=C2=A0=C2=A0 and_some_other_thing();<br>=C2=A0=C2=A0=C2=A0=20
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Malgun Gothic";
panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
{font-family:"\@Malgun Gothic";
panose-1:2 11 5 3 2 0 0 2 0 4;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:107%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
..MsoChpDefault
{font-family:"Calibri","sans-serif";}
..MsoPapDefault
{margin-bottom:8.0pt;
line-height:107%;}
/* Page Definitions */
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
</style>x =3D some(complicated(), expression() + here(whose(type_is(), not =
obvious())) / that(), I_dont_want_to_repeat());<br>=C2=A0 }<br>=C2=A0 and_a=
nother_thing();<br>=C2=A0 std::cout << x;<br>}<br><br>C++ doesn't=
allow the usage of auto in this manner. The best workaround I can think of=
would involve using decltype and repeating "some(complicated(), expre=
ssion() + here(whose(type_is(), not obvious())) / that(), I_dont_want_to_re=
peat())" on the line where x is declared. As the expression indicates,=
this need to repeat might go against the programmer's wishes.<br><br>I=
n principle, the programmer's wishes can be respected here. We can foll=
ow the same rules as return type deduction. If x is reassigned later with a=
different type, the code should simply fail to compile.<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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_3091_528198320.1452727377304--
------=_Part_3090_80176470.1452727377304--
.
------=_Part_2_1408488381.1452733129314
Content-Type: multipart/alternative;
boundary="----=_Part_3_247375556.1452733129314"
------=_Part_3_247375556.1452733129314
Content-Type: text/plain; charset=UTF-8
I'd like to propose the variable-equivalent of auto return-type deduction.
Consider the following motivating example:
void do_something() {
auto x; // default construct
if (some_flag()) {
auto y = do_something_else() + which(involves_some(complicated() +
expression()));
x = another(y, complicated(), expression() + whose(type_is(), not
obvious()));
}
and_another_thing();
std::cout << x;
}
C++ doesn't allow the usage of auto in this manner. There are no easy
workarounds - a solution with decltype would require copying the two large
expressions to which x and y are assigned.
In principle, the c++ language can be extended to accept the above code. We
can follow the same rules as return type deduction. If x is reassigned
later with a different type, the code should simply fail to compile.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3_247375556.1452733129314
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'd like to propose the variable-equivalent of auto re=
turn-type deduction.<br><br>Consider the following motivating example:<br><=
br>void do_something() {<br>=C2=A0 auto x;=C2=A0 // default construct<br>=
=C2=A0 if (some_flag()) {<br>=C2=A0 =C2=A0 auto y =3D do_something_else() +=
which(involves_some(complicated() + expression()));<br>=C2=A0 =C2=A0 x =3D=
another(y, complicated(), expression() + whose(type_is(), not obvious()));=
<br>=C2=A0 }<br>=C2=A0 and_another_thing();<br>=C2=A0 std::cout << x;=
<br>}<br><br>C++ doesn't allow the usage of auto in this manner. There =
are no easy workarounds - a solution with decltype would require copying th=
e two large expressions to which x and y are assigned.=C2=A0<div><br></div>=
<div>In principle, the c++ language can be extended to accept the above cod=
e. We can follow the same rules as return type deduction. If x is reassigne=
d later with a different type, the code should simply fail to compile.<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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_3_247375556.1452733129314--
------=_Part_2_1408488381.1452733129314--
.
On 2016-01-13 18:22, shin.david@gmail.com wrote:
> I'd like to propose the variable-equivalent of auto return-type deduction.
>
> Consider the following motivating example:
>
> void do_something() {
> auto x; // default construct
> if (some_flag()) {
> do_something_else();
> and_some_other_thing();
> x = some(complicated(), expression() + here(whose(type_is(), not
> obvious())) / that(), I_dont_want_to_repeat());
> }
> and_another_thing();
> std::cout << x;
> }
void do_something() {
auto f = auto&& [...](...){
return some(complicated(),
expression() + here(whose(type_is(),
not obvious())) / that(),
I_dont_want_to_repeat());
}
decltype(f()) x;
if (some_flag())
{
do_something_else();
and_some_other_thing();
x = f(...);
}
and_another_thing();
std::cout << x;
}
Not pretty, but I don't see much hope for introducing forward look-ahead
type deduction. Especially after how much auto has been hyped for making
it impossible to forget to initialize a variable, which this would
negate. (At best, you'd need to use a different syntax.)
> The best workaround I can think of would involve using decltype and
> repeating [complicated expression] on the line where x is declared.
Well, I just showed an alternative :-). It's still a little ugly, but at
least doesn't repeat the big mess. (Not tested; may contain errors, but
should suffice to convey the idea.)
> In principle, the programmer's wishes can be respected here. We can follow
> the same rules as return type deduction. If x is reassigned later with a
> different type, the code should simply fail to compile.
....but what if the "different type" can be converted to the desired
type? What if *both* types are convertible to each other; which one
would win?
The lambda doesn't have this problem. (And hopefully your compiler will
inline it away.)
--
Matthew
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
------=_Part_303_2034822121.1452792559943
Content-Type: multipart/alternative;
boundary="----=_Part_304_529005094.1452792559943"
------=_Part_304_529005094.1452792559943
Content-Type: text/plain; charset=UTF-8
On Thursday, January 14, 2016 at 11:11:01 AM UTC-6, Matthew Woehlke wrote:
>
> On 2016-01-13 18:22, shin....@gmail.com <javascript:> wrote:
> > I'd like to propose the variable-equivalent of auto return-type
> deduction.
> >
> > Consider the following motivating example:
> >
> > void do_something() {
> > auto x; // default construct
> > if (some_flag()) {
> > do_something_else();
> > and_some_other_thing();
> > x = some(complicated(), expression() + here(whose(type_is(), not
> > obvious())) / that(), I_dont_want_to_repeat());
> > }
> > and_another_thing();
> > std::cout << x;
> > }
>
> void do_something() {
> auto f = auto&& [...](...){
> return some(complicated(),
> expression() + here(whose(type_is(),
> not obvious())) / that(),
> I_dont_want_to_repeat());
> }
>
> decltype(f()) x;
> if (some_flag())
> {
> do_something_else();
> and_some_other_thing();
> x = f(...);
> }
> and_another_thing();
> std::cout << x;
> }
>
>
I actually quickly deleted my original post and replied with a slightly
modified one. Seems you are replying to the original deleted post.
In my modified post, the if-statement contains an auto y, which is passed
into the hideous expression. This makes it tougher to get by with the
lambda approach. Especially if that variable y is used for other purposes
unrelated to x.
> Not pretty, but I don't see much hope for introducing forward look-ahead
> type deduction. Especially after how much auto has been hyped for making
> it impossible to forget to initialize a variable, which this would
> negate. (At best, you'd need to use a different syntax.)
>
>
If you forget to initialize the variable, the compiler will still complain.
It's just the compiler error would look a little different (something like,
"failed to deduce type").
> > The best workaround I can think of would involve using decltype and
> > repeating [complicated expression] on the line where x is declared.
>
> Well, I just showed an alternative :-). It's still a little ugly, but at
> least doesn't repeat the big mess. (Not tested; may contain errors, but
> should suffice to convey the idea.)
>
> > In principle, the programmer's wishes can be respected here. We can
> follow
> > the same rules as return type deduction. If x is reassigned later with a
> > different type, the code should simply fail to compile.
>
> ...but what if the "different type" can be converted to the desired
> type? What if *both* types are convertible to each other; which one
> would win?
>
Does it not make sense to just say, "do it the same way that c++14's return
type deduction does it"? I.e., all returns/assigments must be of the same
type.
>
> The lambda doesn't have this problem. (And hopefully your compiler will
> inline it away.)
>
> --
> Matthew
>
>
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_304_529005094.1452792559943
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br>On Thursday, January 14, 2016 at 11:11:01 AM UTC-6, Matthew Woehlke wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On 2016-01-13 18:22, <a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"IlkHSSosFgAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">shin....@gm=
ail.com</a> wrote:
<br>> I'd like to propose the variable-equivalent of auto return-typ=
e deduction.
<br>>=20
<br>> Consider the following motivating example:
<br>>=20
<br>> void do_something() {
<br>> =C2=A0 auto x; =C2=A0// default construct
<br>> =C2=A0 if (some_flag()) {
<br>> =C2=A0 =C2=A0 do_something_else();
<br>> =C2=A0 =C2=A0 and_some_other_thing();
<br>> =C2=A0 =C2=A0 x =3D some(complicated(), expression() + here(whose(=
type_is(), not=20
<br>> obvious())) / that(), I_dont_want_to_repeat());
<br>> =C2=A0 }
<br>> =C2=A0 and_another_thing();
<br>> =C2=A0 std::cout << x;
<br>> }
<br>
<br>=C2=A0 void do_something() {
<br>=C2=A0 =C2=A0 auto f =3D auto&& [...](...){
<br>=C2=A0 =C2=A0 =C2=A0 return some(complicated(),
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 expressi=
on() + here(whose(type_is(),
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 not obvious())) / that(),
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I_dont_w=
ant_to_repeat());
<br>=C2=A0 =C2=A0 }
<br>
<br>=C2=A0 =C2=A0 decltype(f()) x;
<br>=C2=A0 =C2=A0 if (some_flag())
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 do_something_else();
<br>=C2=A0 =C2=A0 =C2=A0 and_some_other_thing();
<br>=C2=A0 =C2=A0 =C2=A0 x =3D f(...);
<br>=C2=A0 =C2=A0 }
<br>=C2=A0 =C2=A0 and_another_thing();
<br>=C2=A0 =C2=A0 std::cout << x;
<br>=C2=A0 }
<br>
<br></blockquote><div><br>I actually quickly deleted my original post and r=
eplied with a slightly=20
modified one. Seems you are replying to the original deleted post.<br><br>I=
n my modified post, the if-statement contains an auto y, which is passed in=
to the hideous expression. This makes it tougher to get by with the lambda =
approach. Especially if that variable y is used for other purposes unrelate=
d to x.<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Not=
pretty, but I don't see much hope for introducing forward look-ahead
<br>type deduction. Especially after how much auto has been hyped for makin=
g
<br>it impossible to forget to initialize a variable, which this would
<br>negate. (At best, you'd need to use a different syntax.)
<br>
<br></blockquote><div><br>If you forget to initialize the variable, the com=
piler will still complain. It's just the compiler error would look a li=
ttle different (something like, "failed to deduce type"). <br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> The best workaro=
und I can think of would involve using decltype and
<br>> repeating [complicated expression] on the line where x is declared=
..
<br>
<br>Well, I just showed an alternative :-). It's still a little ugly, b=
ut at
<br>least doesn't repeat the big mess. (Not tested; may contain errors,=
but
<br>should suffice to convey the idea.)
<br>
<br>> In principle, the programmer's wishes can be respected here. W=
e can follow=20
<br>> the same rules as return type deduction. If x is reassigned later =
with a=20
<br>> different type, the code should simply fail to compile.
<br>
<br>...but what if the "different type" can be converted to the d=
esired
<br>type? What if *both* types are convertible to each other; which one
<br>would win?
<br></blockquote><div><br>Does it not make sense to just say, "do it t=
he same way that c++14's return type deduction does it"? I.e., all=
returns/assigments must be of the same type.<br>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
<br>The lambda doesn't have this problem. (And hopefully your compiler =
will
<br>inline it away.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote>
<p></p>
-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_304_529005094.1452792559943--
------=_Part_303_2034822121.1452792559943--
.
On 2016-01-14 12:29, shin.david@gmail.com wrote:
> I actually quickly deleted my original post and replied with a slightly=
=20
> modified one. Seems you are replying to the original deleted post.
You can't delete (or "take back") e-mail=C2=B9. I'm replying to the first
message I received. (In the future, I'd encourage posting a
clarification rather than spamming people with redundant messages. It's
much less confusing, and, well, double-posting just looks bad.)
(=C2=B9 *Maybe* in some very unusual/rare situations where you have control
of the receiving server(s) and the only access is via web clients.
Definitely not stuff posted to a public list.)
> In my modified post, the if-statement contains an auto y, which is passed=
=20
> into the hideous expression. This makes it tougher to get by with the=20
> lambda approach.
Since assignment to 'x' is the only side effect visible in local scope
outside of the if(), the rest can just move into the lambda. You haven't
yet shown a reasonable example where "harder" =3D=3D "impossible".
> On Thursday, January 14, 2016 at 11:11:01 AM UTC-6, Matthew Woehlke wrote=
:
>> Not pretty, but I don't see much hope for introducing forward look-ahead=
=20
>> type deduction. Especially after how much auto has been hyped for making=
=20
>> it impossible to forget to initialize a variable, which this would=20
>> negate. (At best, you'd need to use a different syntax.)=20
>
> If you forget to initialize the variable, the compiler will still complai=
n.=20
> It's just the compiler error would look a little different (something lik=
e,=20
> "failed to deduce type").
delayed_auto x;
if (condition)
x =3D 5; // decltype(x) =3D=3D int
foo(x);
Do you guarantee zero-initialization here (which would be a change from
'int x;')? Or is x possibly uninitialized when foo(x) is called? Note
that a possible compiler warning is not the same as the code being
ill-formed. One of the touted advantages of AAA is that it's ill-formed
to write a declaration that does not include explicit initialization. I
suspect if your proposed feature would break that, you'll meet more
resistance than if you propose a new syntax.
>> On 2016-01-13 18:22, shin.david@gmail.com wrote:
>>> In principle, the programmer's wishes can be respected here. We=20
>>> can follow the same rules as return type deduction. If x is=20
>>> reassigned later with a different type, the code should simply
>>> fail to compile.
>>=20
>> ...but what if the "different type" can be converted to the desired=20
>> type? What if *both* types are convertible to each other; which one=20
>> would win?=20
>=20
> Does it not make sense to just say, "do it the same way that c++14's retu=
rn=20
> type deduction does it"? I.e., all returns/assignments must be of the sam=
e=20
> type.
Perhaps.
I still suspect you'll have trouble getting such a feature accepted. But
what do I know? Write a proposal and present it, if you feel strongly
enough...
--=20
Matthew
--=20
---=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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
.