Topic: Something is better then nothing: Please,
Author: "D. B." <db0451@gmail.com>
Date: Sun, 18 Sep 2016 15:26:23 +0100
Raw View
--001a114b2fc4ead83e053cc8faa1
Content-Type: text/plain; charset=UTF-8
Not including a statement of intended type would be obfuscation, even if it
didn't require your idea of a fundamental change to the language - to add
asymmetry to comparison and ternary operators. If I may presume: that's
just not going to happen. And I don't want it to.
*there is no way to know in advance (for a novice) which operation will
> accepts {} and which not - *the user will have to learn, through trail
> and error, which combo is hardcoded to work.
>
Yes, there is. The novice should train themselves in the language. Then
it's very clear.
Your proposal, among other things, seems to introduce *more* esoteric
hard-coded rules and *more* requirements for trial and error, not to
mention more hassle for compiler authors.
The language already went through a rather huge change to make {} deduce to
an std::initializer_list in cases where the type isn't unambiguously
specified elsewhere. It is massively unlikely that they will revert that
now;.
--
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/CACGiwhF8tQhwuhsLW8mBgE685kRvkmck-GAhcHWrz58ZebdxFQ%40mail.gmail.com.
--001a114b2fc4ead83e053cc8faa1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Not including a statement of intended type would be obfusc=
ation, even if it didn't require your idea of a fundamental change to t=
he language - to add asymmetry to comparison and ternary operators. If I ma=
y presume: that's just not going to happen. And I don't want it to.=
<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><i>there is no wa=
y to know in advance (for a novice) which operation will accepts {} and whi=
ch not - </i>the user will have to learn, through trail and error, which co=
mbo is hardcoded to work. <br></blockquote><div><br></div><div>Yes, there i=
s. The novice should train themselves in the language. Then it's very c=
lear.<br><br></div><div>Your proposal, among other things, seems to introdu=
ce <b>more</b> esoteric hard-coded rules and <b>more</b> requirements for t=
rial and error, not to mention more hassle for compiler authors.<br><br></d=
iv><div>The language already went through a rather huge change to make {} d=
educe to an std::initializer_list in cases where the type isn't unambig=
uously specified elsewhere. It is massively unlikely that they will revert =
that now;. <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/CACGiwhF8tQhwuhsLW8mBgE685kRvkmck-GAh=
cHWrz58ZebdxFQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhF8tQhwuhsL=
W8mBgE685kRvkmck-GAhcHWrz58ZebdxFQ%40mail.gmail.com</a>.<br />
--001a114b2fc4ead83e053cc8faa1--
.
Author: mihailnajdenov@gmail.com
Date: Sun, 18 Sep 2016 08:22:16 -0700 (PDT)
Raw View
------=_Part_36_845182538.1474212136566
Content-Type: multipart/alternative;
boundary="----=_Part_37_1105757215.1474212136567"
------=_Part_37_1105757215.1474212136567
Content-Type: text/plain; charset=UTF-8
Considering, 10 years later, there will be no permanent, "right" solution,
as it seems, ever (not to mention it will undoubtedly be much more
complex).
I am willing to "sacrifice" symmetry to get 90%+ of the usage. I put quotes
because I have never ever wanted to write the arguments in the revere
order, to write a naked {} first.
As for the usefulness for the feature itself, I think It is beyond a doubt.
There are many, many places, *in everyday code, not some obscure,
write-once library*, where semantically there is no ambiguity what one is
trying to achieve, using the forbidden cases.
The original paper is also aware of it. It is only a technical limitation.
--
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/81fdf690-a0fd-42ae-985b-faf1a9399550%40isocpp.org.
------=_Part_37_1105757215.1474212136567
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Considering, 10 years later, there will be no permanent, &=
quot;right" solution, as it seems, ever (not to mention it will undoub=
tedly be much more complex).=C2=A0<div>I am willing to "sacrifice"=
; symmetry to get 90%+ of the usage. I put quotes because I have never ever=
wanted to write the arguments in the revere order, to write a naked {} fir=
st.=C2=A0<div><br></div><div>As for the usefulness for the feature itself, =
I think It is beyond a doubt.=C2=A0</div><div>There are many, many places, =
<i>in everyday code, not some obscure, write-once library</i>, where semant=
ically there is no ambiguity what one is trying to achieve, using the forbi=
dden cases.</div><div><br></div><div>The original paper is also aware of it=
.. It is only a technical limitation.</div><div><br></div><div><br></div></d=
iv></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/81fdf690-a0fd-42ae-985b-faf1a9399550%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/81fdf690-a0fd-42ae-985b-faf1a9399550=
%40isocpp.org</a>.<br />
------=_Part_37_1105757215.1474212136567--
------=_Part_36_845182538.1474212136566--
.
Author: "D. B." <db0451@gmail.com>
Date: Sun, 18 Sep 2016 16:28:29 +0100
Raw View
--047d7bea38c4f8f295053cc9d809
Content-Type: text/plain; charset=UTF-8
>
> I am willing to "sacrifice" symmetry to get 90%+ of the usage.
That's nice for you. I'm not. But good luck convincing the Committee to
your point of view.
The original paper is also aware of it. It is only a technical limitation.
>
It wasn't "only a technical limitation". They also thought that removing
said limitation would be a kludge, from which I might infer they meant
unintuitive and prone to ugly code:
> We suspect that allowing initializer lists as right-hand, but nor [sic] as
> left-hand arguments to most operators is too much of a kludge
>
And I agree. But again, you're welcome to pursue support from other users
if you wish.
--
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/CACGiwhEPNmfxcgDYGrqoAvrCueDcjgD%3DLs4KiA5PRi18ACVKEA%40mail.gmail.com.
--047d7bea38c4f8f295053cc9d809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am wil=
ling to "sacrifice" symmetry to get 90%+ of the usage.</blockquot=
e><div><br></div><div>That's nice for you. I'm not. But good luck c=
onvincing the Committee to your point of view.<br><br><br></div><blockquote=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex" class=3D"gmail_quote"><div>The original paper is also awar=
e of it. It is only a technical limitation.</div></blockquote><div>=C2=A0</=
div><div>It wasn't "only a technical limitation". They also t=
hought that removing said limitation would be a kludge, from which I might =
infer they meant unintuitive and prone to ugly code:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">We suspect that allowing initializer lists=
as right-hand, but nor [sic]=20
as left-hand arguments to most operators is too much of a kludge<br></block=
quote><div><br><br></div><div>And I agree. But again, you're welcome to=
pursue support from other users if you wish.<br>=C2=A0<br></div></div></di=
v>
<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/CACGiwhEPNmfxcgDYGrqoAvrCueDcjgD%3DLs=
4KiA5PRi18ACVKEA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEPNmfxcg=
DYGrqoAvrCueDcjgD%3DLs4KiA5PRi18ACVKEA%40mail.gmail.com</a>.<br />
--047d7bea38c4f8f295053cc9d809--
.
Author: mihailnajdenov@gmail.com
Date: Sun, 18 Sep 2016 08:57:11 -0700 (PDT)
Raw View
------=_Part_3075_1956430182.1474214231676
Content-Type: multipart/alternative;
boundary="----=_Part_3076_1154519686.1474214231676"
------=_Part_3076_1154519686.1474214231676
Content-Type: text/plain; charset=UTF-8
I meant, it is a technical limitation to have the full feature.
Considering this technical limitation proved to be too great - ".., we try
to express a more general rule." never materialized in 10 years and the
solution WILL be complex - I just wanted to suggest, It might be worth
considering "concepts-light" edition on the issue. To make a reasonable, in
my opinion, sacrifice to get well over 90% of this great feature.
--
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/28d7b712-a976-43fc-b604-5ca75ad86759%40isocpp.org.
------=_Part_3076_1154519686.1474214231676
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I meant, it is a technical limitation to have the full fea=
ture.=C2=A0<div>Considering this technical limitation proved to be too grea=
t - =C2=A0".., we try to express a more general rule." never mate=
rialized in 10 years and the solution WILL be complex - I just wanted to su=
ggest, It might be worth considering "concepts-light" edition on =
the issue. To make a reasonable, in my opinion, sacrifice to get well over =
90% of this great feature.=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" 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/28d7b712-a976-43fc-b604-5ca75ad86759%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28d7b712-a976-43fc-b604-5ca75ad86759=
%40isocpp.org</a>.<br />
------=_Part_3076_1154519686.1474214231676--
------=_Part_3075_1956430182.1474214231676--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 18 Sep 2016 18:59:33 +0200
Raw View
--94eb2c049406aa50a9053ccb1ea0
Content-Type: text/plain; charset=UTF-8
Am 18.09.2016 15:08 schrieb "Nicol Bolas" <jmckesson@gmail.com>:
>
> On Sunday, September 18, 2016 at 8:41:39 AM UTC-4, mihailn...@gmail.com
wrote:
>>
>> Hello, in a recent search about why is Initializer List limited so much
(cant be used in arithmetics, assignment, etc), I came to this post :
http://stackoverflow.com/a/11445905/362515
>>
>> Basically the problem is, Initializer List is impossible to work in any
situation where operators are used - parsing such an expression will be to
complex.
>>
>> That is fine.
>>
>> However support in limited, but well defined scenarios is possible and I
believe the benefits will still outweigh the confusion why it is not
working in some contexts.
>> What is more there is already a confusion why it is not working in
"similar contexts"!
>>
>> For example from the user perspective assignment and comparison are
"similar" contexts of use - one is "are you that thing" the other is
"become that thing".
>> Needless to say the syntax is, as we know, dangerously close "==" vs "=".
>>
>> If for instance is allowed only the type of the RHS in operator to be
deduced from an init-list and expression is dissuaded to start with a
init-list, not only many if not all use cases will be possible, but it will
be somewhat easier to teach why the other case is to available.
>>
>> Back to the example - it is hard to explain why this is working:
>> Point p;
>> p = {-1, -1};
>>
>> but this is not:
>>
>> if(p == {-1, -1}) return;
>>
>
> Because one is assignment while the other is equality testing. They're
two different things.
>
You habe just explained it in terms of how the compiler deduces the
illformedness. "one is this and one is that. And the language forbids that
and now this". That is not an explanation of the "why" but more of the
"how" i guess,
> Why is that hard to explain?
>
>>
>> But this is actually relatively easy to explain why it's not working:
>> if({-1, -1} == p) return;
>>
>
> Um, no. If we allow `X == Y` to work, then it makes sense that we allow
`Y == X` to work. To disallow one and not the other is far more bizarre
than allowing one operation but forbidding a completely different one.
>
I agree.
>> Bonus:
>> This must work, it really must work:
>> const auto e = car ? car->engine() : {};
>> We know it does not but it should, no reason why not - first arg is
given, second arg is given, the the third must the same type as the second,
so we have everything to deduce it!
>
>
> Again, that goes back to consistency. `!car ? {} : car->engine()` is
conceptually the same, yet it wouldn't work under your scheme.
>
Why? Two arg types are known. The third arg types will just initialize a
value of that one branches type.
This is conceptually remotely consistent with the treatment of init list as
nondeduced contexts, in which the initlist will initialize a parameter type
that is determined elsewhere.
--
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/CANu6V4Vdycy-Mse5bB3unJZyFCrJ85ruxsDdwe91e7BQLBEudA%40mail.gmail.com.
--94eb2c049406aa50a9053ccb1ea0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"></p>
<p dir=3D"ltr">Am 18.09.2016 15:08 schrieb "Nicol Bolas" <<a h=
ref=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>>:<br>
><br>
> On Sunday, September 18, 2016 at 8:41:39 AM UTC-4, <a href=3D"mailto:m=
ihailn...@gmail.com">mihailn...@gmail.com</a> wrote:<br>
>><br>
>> Hello, in a recent search about why is Initializer List limited so=
much (cant be used in arithmetics, assignment, etc), I came to this post :=
=C2=A0<a href=3D"http://stackoverflow.com/a/11445905/362515">http://stackov=
erflow.com/a/11445905/362515</a><br>
>><br>
>> Basically the problem is, Initializer List is impossible to work i=
n any situation where operators are used - parsing such an expression will =
be to complex.<br>
>><br>
>> That is fine.<br>
>><br>
>> However support in limited, but well defined scenarios is possible=
and I believe the benefits will still outweigh the confusion why it is not=
working in some contexts.=C2=A0<br>
>> What is more there is already a=C2=A0confusion why it is not worki=
ng in "similar contexts"!=C2=A0<br>
>><br>
>> For example from the user perspective assignment and comparison ar=
e "similar" contexts of use - one is "are you that thing&quo=
t; the other is "become that thing".=C2=A0<br>
>> Needless to say the syntax is, as we know, dangerously close "=
;=3D=3D" vs "=3D".<br>
>><br>
>> If for instance is allowed only the type of =C2=A0the RHS in opera=
tor to be deduced from an init-list=C2=A0and expression is dissuaded to sta=
rt with a init-list, not only many if not all use cases will be possible, b=
ut it will be somewhat easier to teach why the other case is to available.<=
br>
>><br>
>> Back to the example - it is hard to explain why this is working:<b=
r>
>> Point p;<br>
>> p =3D {-1, -1};<br>
>><br>
>> but this is not:<br>
>><br>
>> if(p =3D=3D {-1, -1}) return;<br>
>><br>
><br>
> Because one is assignment while the other is equality testing. They=
9;re two different things.<br>
></p>
<p dir=3D"ltr">You habe just explained it in terms of how the compiler dedu=
ces the illformedness. "one is this and one is that. And the language =
forbids that and now this". That is not an explanation of the "wh=
y" but more of the "how" i guess,<br><br></p>
<p dir=3D"ltr">> Why is that hard to explain?<br>
><br>
>><br>
>> But this is actually relatively easy to explain why it's not w=
orking:<br>
>> if({-1, -1} =3D=3D p) return;<br>
>><br>
><br>
> Um, no. If we allow `X =3D=3D Y` to work, then it makes sense that we =
allow `Y =3D=3D X` to work. To disallow one and not the other is far more b=
izarre than allowing one operation but forbidding a completely different on=
e. <br>
></p>
<p dir=3D"ltr">I agree. </p>
<p dir=3D"ltr">>> Bonus:<br>
>> This must work, it really must work:<br>
>> const auto e =3D car ? car->engine() : {};<br>
>> =C2=A0We know it does not but it should, no reason why not - first=
arg is given, second arg is given, the the third must the same type as the=
second, so we have everything to deduce it!<br>
><br>
><br>
> Again, that goes back to consistency. `!car ? {} : car->engine()` i=
s conceptually the same, yet it wouldn't work under your scheme.<br>
></p>
<p dir=3D"ltr">Why? Two arg types are known. The third=C2=A0 arg types will=
just initialize a value of that one branches type. </p>
<p dir=3D"ltr">This is conceptually remotely consistent with the treatment =
of init list as nondeduced contexts, in which the initlist will initialize =
a parameter type that is determined elsewhere.</p>
<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/CANu6V4Vdycy-Mse5bB3unJZyFCrJ85ruxsDd=
we91e7BQLBEudA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4Vdycy-Mse5=
bB3unJZyFCrJ85ruxsDdwe91e7BQLBEudA%40mail.gmail.com</a>.<br />
--94eb2c049406aa50a9053ccb1ea0--
.
Author: "'Johannes Schaub' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 18 Sep 2016 19:03:59 +0200
Raw View
--001a114049628a4553053ccb2e78
Content-Type: text/plain; charset=UTF-8
Am 18.09.2016 15:08 schrieb "Nicol Bolas" <jmckesson@gmail.com>:
>
> On Sunday, September 18, 2016 at 8:41:39 AM UTC-4, mihailn...@gmail.com
wrote:
>>
>> Hello, in a recent search about why is Initializer List limited so much
(cant be used in arithmetics, assignment, etc), I came to this post :
http://stackoverflow.com/a/11445905/362515
>>
>> Basically the problem is, Initializer List is impossible to work in any
situation where operators are used - parsing such an expression will be to
complex.
>>
>> That is fine.
>>
>> However support in limited, but well defined scenarios is possible and I
believe the benefits will still outweigh the confusion why it is not
working in some contexts.
>> What is more there is already a confusion why it is not working in
"similar contexts"!
>>
>> For example from the user perspective assignment and comparison are
"similar" contexts of use - one is "are you that thing" the other is
"become that thing".
>> Needless to say the syntax is, as we know, dangerously close "==" vs "=".
>>
>> If for instance is allowed only the type of the RHS in operator to be
deduced from an init-list and expression is dissuaded to start with a
init-list, not only many if not all use cases will be possible, but it will
be somewhat easier to teach why the other case is to available.
>>
>> Back to the example - it is hard to explain why this is working:
>> Point p;
>> p = {-1, -1};
>>
>> but this is not:
>>
>> if(p == {-1, -1}) return;
>>
>
> Because one is assignment while the other is equality testing. They're
two different things.
>
> Why is that hard to explain?
>
>>
>> But this is actually relatively easy to explain why it's not working:
>> if({-1, -1} == p) return;
>>
>
> Um, no. If we allow `X == Y` to work, then it makes sense that we allow
`Y == X` to work. To disallow one and not the other is far more bizarre
than allowing one operation but forbidding a completely different one.
>
However, C++ already has precedent of this asymmetry. Member operator
overloads are already looked up only in the left hand side class object.
--
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/CANu6V4XLwSgijoyUy%2BWSHp8mrc46_a4GLQUq6NGRTF7ZLPimMg%40mail.gmail.com.
--001a114049628a4553053ccb2e78
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"></p>
<p dir=3D"ltr">Am 18.09.2016 15:08 schrieb "Nicol Bolas" <<a h=
ref=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>>:<br>
><br>
> On Sunday, September 18, 2016 at 8:41:39 AM UTC-4, <a href=3D"mailto:m=
ihailn...@gmail.com">mihailn...@gmail.com</a> wrote:<br>
>><br>
>> Hello, in a recent search about why is Initializer List limited so=
much (cant be used in arithmetics, assignment, etc), I came to this post :=
=C2=A0<a href=3D"http://stackoverflow.com/a/11445905/362515">http://stackov=
erflow.com/a/11445905/362515</a><br>
>><br>
>> Basically the problem is, Initializer List is impossible to work i=
n any situation where operators are used - parsing such an expression will =
be to complex.<br>
>><br>
>> That is fine.<br>
>><br>
>> However support in limited, but well defined scenarios is possible=
and I believe the benefits will still outweigh the confusion why it is not=
working in some contexts.=C2=A0<br>
>> What is more there is already a=C2=A0confusion why it is not worki=
ng in "similar contexts"!=C2=A0<br>
>><br>
>> For example from the user perspective assignment and comparison ar=
e "similar" contexts of use - one is "are you that thing&quo=
t; the other is "become that thing".=C2=A0<br>
>> Needless to say the syntax is, as we know, dangerously close "=
;=3D=3D" vs "=3D".<br>
>><br>
>> If for instance is allowed only the type of =C2=A0the RHS in opera=
tor to be deduced from an init-list=C2=A0and expression is dissuaded to sta=
rt with a init-list, not only many if not all use cases will be possible, b=
ut it will be somewhat easier to teach why the other case is to available.<=
br>
>><br>
>> Back to the example - it is hard to explain why this is working:<b=
r>
>> Point p;<br>
>> p =3D {-1, -1};<br>
>><br>
>> but this is not:<br>
>><br>
>> if(p =3D=3D {-1, -1}) return;<br>
>><br>
><br>
> Because one is assignment while the other is equality testing. They=
9;re two different things.<br>
><br>
> Why is that hard to explain?<br>
><br>
>><br>
>> But this is actually relatively easy to explain why it's not w=
orking:<br>
>> if({-1, -1} =3D=3D p) return;<br>
>><br>
><br>
> Um, no. If we allow `X =3D=3D Y` to work, then it makes sense that we =
allow `Y =3D=3D X` to work. To disallow one and not the other is far more b=
izarre than allowing one operation but forbidding a completely different on=
e. <br>
></p>
<p dir=3D"ltr">However, C++ already has precedent of this asymmetry. Member=
operator overloads are already looked up only in the left hand side class =
object. </p>
<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/CANu6V4XLwSgijoyUy%2BWSHp8mrc46_a4GLQ=
Uq6NGRTF7ZLPimMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANu6V4XLwSgijo=
yUy%2BWSHp8mrc46_a4GLQUq6NGRTF7ZLPimMg%40mail.gmail.com</a>.<br />
--001a114049628a4553053ccb2e78--
.
Author: mihailnajdenov@gmail.com
Date: Sun, 18 Sep 2016 11:58:26 -0700 (PDT)
Raw View
------=_Part_170_1611533208.1474225106872
Content-Type: multipart/alternative;
boundary="----=_Part_171_145536444.1474225106872"
------=_Part_171_145536444.1474225106872
Content-Type: text/plain; charset=UTF-8
>
> > Um, no. If we allow `X == Y` to work, then it makes sense that we allow
> `Y == X` to work. To disallow one and not the other is far more bizarre
> than allowing one operation but forbidding a completely different one.
> >
>
> However, C++ already has precedent of this asymmetry. Member operator
> overloads are already looked up only in the left hand side class object.
>
I want to stress out again, it is not true asymmetry. It is not like "a
value of type Y cannot be compared (or looked up to select operator) to a
value of type X, although the opposite is true".
The case is - smart init-list overload deduction can be activated as long
it is valid expression.
{-1, -1} == p will not be considered a valid expression, because the parser
will not be bothered to go backwards to do magic for you.
You have two options then:
1. if you want magic from me - arrange the code, so I can read it from
left to right as you know I do for decades, the meaning is the same
anyways! (You lose nothing and gain magic)
2. give me type manually and forget about magic. (If you want deduction
you can do decay_t<decltype()p>{-1, -1} )
Let me give the same example in a different form.
//does not:
if(-1 == x)
//works:
if(x == -1)
*This is true asymmetry*, because we have valid statements: create integer
with value -1, use x to call ==
However
if(p == {-1, -1})
//vs
if({-1, -1} == p)
*BOTH **of these are completely different from the above int example!
Both! *
*And this is clear from the point of view of the user - he did not create
any objects!*
*The user knows, even a beginner I argue, he started some sort of
autodeduction! *
*We are one level "above" the actual comparison, we are preparing for it,
and the user knows it. *
*Even a child will guess, "mr. Computer" at some point will have to decide
if the {} is a Point or is it a Size I want to compare to.*
And here, in this high realm, we introduce,
"mr. Computer" does not look forward, then go back, then go forward again, *you
can't start asking for magic first, dear, you have to give something first.*
"But why -1 == p worked?" (asked the child)
"Remember, you were very specific in your request, you did not ask magic
from me, you gave me object type, you can do the same again, no problem.
For magic, or do as I ask of you."
Yes, there is no symmetry *in the higher realm*. *But this ream is new,
there is nothing like it before, the rules can change (a bit) if the prize
is magic. *
One somewhat related example - auto is magic, auto is a substitution of
type, auto can be omitted or can be manually or substituted for a type.
These are interchangeable, there is "symmetry"
*Except when auto can't be substituted manually for a 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/383678c9-b065-4313-a199-19e9536e6c33%40isocpp.org.
------=_Part_171_145536444.1474225106872
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr=
">> Um, no. If we allow `X =3D=3D Y` to work, then it makes sense that w=
e allow `Y =3D=3D X` to work. To disallow one and not the other is far more=
bizarre than allowing one operation but forbidding a completely different =
one. <br>
></p>
<p dir=3D"ltr">However, C++ already has precedent of this asymmetry. Member=
operator overloads are already looked up only in the left hand side class =
object. </p></blockquote><div>=C2=A0</div><div>I want to stress out again, =
it is not true asymmetry. It is not like "a value of type Y cannot be =
compared (or looked up to select operator) to a value of type X, although t=
he opposite is true".=C2=A0</div><div><br></div><div>The case is - sma=
rt init-list overload deduction can be activated as long it is valid expres=
sion.=C2=A0</div><div>{-1, -1} =3D=3D p will not be considered a valid expr=
ession, because the parser will not be bothered to go backwards to do magic=
for you.=C2=A0</div><div>You have two options then:</div><div><ol><li>if y=
ou want magic from me - arrange the code, so I can read it from left to rig=
ht as you know I do=C2=A0for decades, the meaning is the same anyways! (You=
lose nothing and gain magic)<br></li><li>give me type manually and forget =
about magic. (If you want deduction you can do decay_t<decltype()p>{-=
1, -1} )</li></ol><div>Let me give the same example in a different form.=C2=
=A0</div></div><div><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #800=
;" class=3D"styled-by-prettify">//does not:</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></font><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(-</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">1</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><fon=
t color=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//w=
orks:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></font><span style=3D"color: #008;" class=3D"styled-by-prettify">if</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><fon=
t color=3D"#006666"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">x</span></font><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">-</span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">)</span><font color=3D"#660066"><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></font><fon=
t color=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span></font></div></code></div><br><i>This is true asymmetry</i>, =
because we have valid statements: create integer with value -1, use x to ca=
ll =3D=3D</div><div><br></div><div>However</div><div><div class=3D"prettypr=
int" 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"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">p </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">{-</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
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: #0=
66;" class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">})</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: rgb(136, 0, 0);"><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">//vs</span></span><font c=
olor=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">({-</span><spa=
n style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span 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: #066;" class=3D"=
styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span></font><fon=
t color=3D"#660066"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span></font></div></code></div><i style=3D"font-weight: bold;"=
><div><i style=3D"font-weight: bold;"><br></i></div>BOTH </i><b>of these ar=
e completely different from the above int example! Both!=C2=A0</b></div><di=
v><b><br></b></div><div><i>And this is clear from the point of view of the =
user - <b>he did not create any objects</b>!</i></div><div><i>The user know=
s, even a beginner I argue, he started some sort of autodeduction!=C2=A0</i=
></div><div><i><br></i></div><div><i>We are one level "above" the=
actual comparison, we are=C2=A0preparing=C2=A0for it, and the user knows i=
t.=C2=A0</i></div><div><i><br></i></div><div><i>Even a child will guess, &q=
uot;mr. Computer" at some point=C2=A0will have to decide if the {} is =
a Point or is it a Size I want to compare to.</i></div><div>And here, in th=
is high realm,<i> </i>we introduce,=C2=A0</div><div>"mr. Computer"=
; does not look forward, then go back, then go forward again, <i>you can=
9;t start asking for magic first, dear, you have to give something first.</=
i></div><div><br></div><div>"But why -1 =3D=3D p worked?" (asked =
the child)</div><div>"Remember, you were very specific in your request=
, you did not ask magic from me, you gave me object type, you can do the sa=
me again, no problem. For magic, or do as I ask of you."</div><div><br=
></div><div>Yes, there is no symmetry <i>in the higher realm</i>. <b>But th=
is ream is new, there is nothing like it before, the rules can change (a bi=
t) if the prize is magic.=C2=A0</b></div><div><br></div><div>One somewhat r=
elated example - auto is magic, auto is a substitution of type, auto can be=
omitted or can be manually or substituted for a type. These are interchang=
eable, there is "symmetry"</div><div><i>Except when auto can'=
t be=C2=A0substituted=C2=A0manually=C2=A0for a type!</i>=C2=A0=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" 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/383678c9-b065-4313-a199-19e9536e6c33%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/383678c9-b065-4313-a199-19e9536e6c33=
%40isocpp.org</a>.<br />
------=_Part_171_145536444.1474225106872--
------=_Part_170_1611533208.1474225106872--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 18 Sep 2016 12:23:18 -0700 (PDT)
Raw View
------=_Part_3038_1597196190.1474226599081
Content-Type: multipart/alternative;
boundary="----=_Part_3039_1043605335.1474226599082"
------=_Part_3039_1043605335.1474226599082
Content-Type: text/plain; charset=UTF-8
On Sunday, September 18, 2016 at 2:58:27 PM UTC-4, mihailn...@gmail.com
wrote:
>
> > Um, no. If we allow `X == Y` to work, then it makes sense that we allow
>> `Y == X` to work. To disallow one and not the other is far more bizarre
>> than allowing one operation but forbidding a completely different one.
>> >
>>
>> However, C++ already has precedent of this asymmetry. Member operator
>> overloads are already looked up only in the left hand side class object.
>>
>
> I want to stress out again, it is not true asymmetry. It is not like "a
> value of type Y cannot be compared (or looked up to select operator) to a
> value of type X, although the opposite is true".
>
Wait a minute.
You want to have this feature, in your words, because it was "hard to
explain why this is working: but this is not:". Yet your explanation of why
one kind of asymmetry is not "true asymmetry" is based on the complex
question of what is a syntactic failure and what is not. That is, what a
"valid statement" is.
It seems to me that you're trading one form of hard to explain incongruity
with another. And that's assuming we buy your belief that the current state
of things is in fact hard to explain.
--
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/5e1a0391-9cca-40df-82a9-e8ba57526c9c%40isocpp.org.
------=_Part_3039_1043605335.1474226599082
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, September 18, 2016 at 2:58:27 PM UTC-4, mihailn=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">> Um, no=
.. If we allow `X =3D=3D Y` to work, then it makes sense that we allow `Y =
=3D=3D X` to work. To disallow one and not the other is far more bizarre th=
an allowing one operation but forbidding a completely different one. <br>
></p>
<p dir=3D"ltr">However, C++ already has precedent of this asymmetry. Member=
operator overloads are already looked up only in the left hand side class =
object. </p></blockquote><div>=C2=A0</div><div>I want to stress out again, =
it is not true asymmetry. It is not like "a value of type Y cannot be =
compared (or looked up to select operator) to a value of type X, although t=
he opposite is true".=C2=A0</div></div></blockquote><div><br>Wait a mi=
nute.<br><br>You want to have this feature, in your words, because it was &=
quot;hard to explain why this is working: but this is not:". Yet your =
explanation of why one kind of asymmetry is not "true asymmetry" =
is based on the complex question of what is a syntactic failure and what is=
not. That is, what a "valid statement" is.<br><br>It seems to me=
that you're trading one form of hard to explain incongruity with anoth=
er. And that's assuming we buy your belief that the current state of th=
ings is in fact hard to explain.<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/5e1a0391-9cca-40df-82a9-e8ba57526c9c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e1a0391-9cca-40df-82a9-e8ba57526c9c=
%40isocpp.org</a>.<br />
------=_Part_3039_1043605335.1474226599082--
------=_Part_3038_1597196190.1474226599081--
.
Author: mihailnajdenov@gmail.com
Date: Sun, 18 Sep 2016 14:35:27 -0700 (PDT)
Raw View
------=_Part_389_144375241.1474234527234
Content-Type: multipart/alternative;
boundary="----=_Part_390_1621790150.1474234527234"
------=_Part_390_1621790150.1474234527234
Content-Type: text/plain; charset=UTF-8
>
>
> Wait a minute.
>
> You want to have this feature, in your words, because it was "hard to
> explain why this is working: but this is not:". Yet your explanation of why
> one kind of asymmetry is not "true asymmetry" is based on the complex
> question of what is a syntactic failure and what is not. That is, what a
> "valid statement" is.
>
> It seems to me that you're trading one form of hard to explain incongruity
> with another. And that's assuming we buy your belief that the current state
> of things is in fact hard to explain.
>
This is what I want to trade:
A relatively new, somewhat confusing, rule for the old confusing (but for
different reasons) rule.
Making this "switch", however, grans considerable new functionality for
everyday use for basically every programmer, especially in this day of age
where simple objects are becoming popular.
Staying with the old rule is fine, one will learn it. But will get *nothing
*(new).
(again I believe the usefulness of the general feature - deducing {,}
statements, quirks or not - is beyond a doubt. If it wasn't important it
would have not be implemented for the current cases already a decade ago.
These are by all means not all useful cases and this is also not a secret)
Waiting for the the rule/implementation to solve all issues, without
quirks, is unrealistic at this point.
*However*, I also argue, not only is the new functionality a plus all by
itself. The new quirk is way better to explain, because it is does not
*seem* to be based on seemingly "illogical limitations" (from a user
perspective!).
The user has only two things to know -
1) {,} means nothing by itself, nothing - it is a helper, a ready-made,
for something "real", depending on the context.
2) This context must come first. ...but things must be written in order
already in the entire language, *even if* it is inconvenient - it is nice
to have function anywhere in a file but you can't - you must place it
before you use it, it is nice to have return type of inner class by name
only in a impl. file, but you can't - you must qualify it or make the
return declaration as a trailing one (excluding the full auto magic, which
is very new). *The compiler will not go forward, then go backwards. *
None of these are truly new. Granted, the context where they appear is
new, yes, the price for the lunch, but the context is also new as well -
one can't truly compare to how we are used to, as I argued in the last
post.
--
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/7a431a82-171c-4d14-a16a-384fe0c07016%40isocpp.org.
------=_Part_390_1621790150.1474234527234
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>Wait a minute.<br><br>You want to have this feature, in your w=
ords, because it was "hard to explain why this is working: but this is=
not:". Yet your explanation of why one kind of asymmetry is not "=
;true asymmetry" is based on the complex question of what is a syntact=
ic failure and what is not. That is, what a "valid statement" is.=
<br><br>It seems to me that you're trading one form of hard to explain =
incongruity with another. And that's assuming we buy your belief that t=
he current state of things is in fact hard to explain.<br></div></div></blo=
ckquote><div><br></div><div>This is what I want to trade:=C2=A0</div><div><=
br></div><div>A relatively new, somewhat confusing, rule for the old confus=
ing (but for different reasons) rule.</div><div>Making this "switch&qu=
ot;, however, grans considerable new functionality for everyday use for bas=
ically every programmer, especially in this day of age where simple objects=
are becoming popular.=C2=A0</div><div><br></div><div>Staying with the old =
rule is fine, one will learn it. But will get <i>nothing </i>(new).=C2=A0</=
div><div>(again I believe the usefulness of the general feature - deducing =
{,} statements, quirks or not - is beyond a doubt. If it wasn't importa=
nt it would have not be implemented for the current cases already a decade =
ago. These are by all means not all useful cases and this is also not a sec=
ret)</div><div><br></div><div>Waiting for the the rule/implementation to so=
lve all issues, without quirks, is unrealistic at this point.=C2=A0</div><d=
iv><br></div><div><br></div><div><b>However</b>, I also argue, not only is =
the new functionality a plus all by itself. The new quirk is way better to =
explain, because it is does not <i>seem</i> to be based on seemingly "=
illogical limitations" (from a user perspective!).</div><div><br></div=
><div>The user has only two things to know -=C2=A0</div><div>=C2=A01) {,} m=
eans nothing by itself, nothing - it is a helper, a ready-made, for somethi=
ng "real", depending on the context.=C2=A0</div><div>=C2=A02) Thi=
s context must come first. ...but things must be written in order already i=
n the entire language,=C2=A0<b>even if</b>=C2=A0it is inconvenient - it is =
nice to have function anywhere in a file but you can't - you must place=
it before you use it, it is nice to have return type of inner class by nam=
e only in a impl. file, but you can't - you must qualify it or make the=
return declaration as a trailing one (excluding the full auto magic, which=
is very new). <i>The compiler will not go forward, then go backwards.=C2=
=A0</i></div><div><i><br></i></div><div>None of these are truly new. Grante=
d, the context where they appear is new,=C2=A0yes,<i>=C2=A0</i>the price fo=
r the lunch, but the context is also new as well - one can't truly comp=
are to how we are used to, as I argued in the last post.=C2=A0</div><div><b=
r></div><div><br></div><div><i><br></i></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/7a431a82-171c-4d14-a16a-384fe0c07016%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a431a82-171c-4d14-a16a-384fe0c07016=
%40isocpp.org</a>.<br />
------=_Part_390_1621790150.1474234527234--
------=_Part_389_144375241.1474234527234--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 19 Sep 2016 22:22:10 +0300
Raw View
On 19 September 2016 at 00:35, <mihailnajdenov@gmail.com> wrote:
> This is what I want to trade:
>
> A relatively new, somewhat confusing, rule for the old confusing (but for
> different reasons) rule.
> Making this "switch", however, grans considerable new functionality for
> everyday use for basically every programmer, especially in this day of ag=
e
> where simple objects are becoming popular.
>
> Staying with the old rule is fine, one will learn it. But will get nothin=
g
> (new).
> (again I believe the usefulness of the general feature - deducing {,}
> statements, quirks or not - is beyond a doubt. If it wasn't important it
> would have not be implemented for the current cases already a decade ago.
> These are by all means not all useful cases and this is also not a secret=
)
>
> Waiting for the the rule/implementation to solve all issues, without quir=
ks,
> is unrealistic at this point.
>
>
> However, I also argue, not only is the new functionality a plus all by
> itself. The new quirk is way better to explain, because it is does not se=
em
> to be based on seemingly "illogical limitations" (from a user perspective=
!).
>
> The user has only two things to know -
> 1) {,} means nothing by itself, nothing - it is a helper, a ready-made, =
for
> something "real", depending on the context.
> 2) This context must come first. ...but things must be written in order
> already in the entire language, even if it is inconvenient - it is nice t=
o
> have function anywhere in a file but you can't - you must place it before
> you use it, it is nice to have return type of inner class by name only in=
a
> impl. file, but you can't - you must qualify it or make the return
> declaration as a trailing one (excluding the full auto magic, which is ve=
ry
> new). The compiler will not go forward, then go backwards.
>
> None of these are truly new. Granted, the context where they appear is ne=
w,
> yes, the price for the lunch, but the context is also new as well - one
> can't truly compare to how we are used to, as I argued in the last post.
Here's what a compiler expert told me, after I asked for his input:
---snip---
> Why doesn't something like
>
> pair<int, int> p;
>
> if (p =3D=3D {1,2})
>
> work? Is there some parsing difficulty involved? I guess making
>
> if ({1,2} =3D=3D p)
>
> work might lead to parsing nightmares?
Yes, it would be a bit painful to specify, I think. We=E2=80=99d presumabl=
y
want an initializer-clause to become a valid primary-expression.
Expression can appear alone in statements (expression statements), but
statements can be blocks with embedded expression statements. So:
{ 1+2+3+4; }
would look like an expression until you hit the =E2=80=9C;=E2=80=9D. I sup=
pose we
could evade that issue by only considering =E2=80=9C{=E2=80=9C to start an =
expression
if no statement can start at that place.
I remember Bjarne discussing this in the early list-init papers, but I
don=E2=80=99t recall the details of the conclusion (I do seem to recall tha=
t
he right away decided to only allow them on the right hand side of
assignments, when it came to non-initializer contexts).
My gut feeling is that there isn=E2=80=99t an insurmountable problem with t=
he
idea though (assuming we allow a leading =E2=80=9C{=E2=80=9C in a statement=
to always
resolve to a block statement).
---snap---
--=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/CAFk2RUasW1ExByuPKkPubzVCNiSS5GQrJCCx9N8SEQgsBDA=
dPw%40mail.gmail.com.
.
Author: mihailnajdenov@gmail.com
Date: Tue, 20 Sep 2016 00:40:39 -0700 (PDT)
Raw View
------=_Part_0_1969963542.1474357239124
Content-Type: multipart/alternative;
boundary="----=_Part_1_797372141.1474357239126"
------=_Part_1_797372141.1474357239126
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>
> ...
> Here's what a compiler expert told me, after I asked for his input:=20
>
> ---snip---=20
> > Why doesn't something like=20
> >=20
> > pair<int, int> p;=20
> >=20
> > if (p =3D=3D {1,2})=20
> >=20
> > work? Is there some parsing difficulty involved? I guess making=20
> >=20
> > if ({1,2} =3D=3D p)=20
> >=20
> > work might lead to parsing nightmares?=20
>
>
> Yes, it would be a bit painful to specify, I think. We=E2=80=99d presuma=
bly=20
> want an initializer-clause to become a valid primary-expression.=20
> Expression can appear alone in statements (expression statements), but=20
> statements can be blocks with embedded expression statements. So:=20
>
> { 1+2+3+4; }=20
>
> would look like an expression until you hit the =E2=80=9C;=E2=80=9D. I s=
uppose we=20
> could evade that issue by only considering =E2=80=9C{=E2=80=9C to start a=
n expression=20
> if no statement can start at that place.=20
>
> I remember Bjarne discussing this in the early list-init papers, but I=20
> don=E2=80=99t recall the details of the conclusion (I do seem to recall t=
hat=20
> he right away decided to only allow them on the right hand side of=20
> assignments, when it came to non-initializer contexts).=20
>
> My gut feeling is that there isn=E2=80=99t an insurmountable problem with=
the=20
> idea though (assuming we allow a leading =E2=80=9C{=E2=80=9C in a stateme=
nt to always=20
> resolve to a block statement).=20
> ---snap---=20
>
=20
Yes, that's the point - *let leading =E2=80=9C{=E2=80=9C be a block stateme=
nt as it always=20
was*.
*In that sense the user will not have to learn something new! He already=20
knows '{' does not start an expression!*
It is worth also nothing, the deduction is more often needed and used on=20
the RHS anyway.
Users write more often if(x =3D=3D -1) and if(ptr !=3D 0), then the other w=
ay=20
around.=20
The reverse needs pretty much be trained, for a specific reason,=20
*if someone has the training to reverse the args, he'll got used to specify=
=20
the type anyway!*
*Also*, some operations do not even make sense if reversed:
PointList list;=20
//expected and much needed behavior:
list << {-1, -1};
// useless anyway:
{-1, -1} << list;
Some will argue, this should work, it is not meaningless:
{-1, -1} >> list;
But, seriously, who writes code like that ?!?=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/3b50c2a8-8625-43c0-994a-bc6887a0d67c%40isocpp.or=
g.
------=_Part_1_797372141.1474357239126
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">...<br>Here's what a compi=
ler expert told me, after I asked for his input:
<br>
<br>---snip---
<br>> Why doesn't something like
<br>>
<br>> pair<int, int> p;
<br>>
<br>> if (p =3D=3D {1,2})
<br>>
<br>> work? Is there some parsing difficulty involved? I guess making
<br>>
<br>> if ({1,2} =3D=3D p)
<br>>
<br>> work might lead to parsing nightmares?
<br>
<br>
<br>Yes, it would be a bit painful to specify, I think. =C2=A0We=E2=80=99d =
presumably
<br>want an initializer-clause to become a valid primary-expression.
<br>Expression can appear alone in statements (expression statements), but
<br>statements can be blocks with embedded expression statements. =C2=A0So:
<br>
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 { 1+2+3+4; }
<br>
<br>would look like an expression until you hit the =E2=80=9C;=E2=80=9D. =
=C2=A0I suppose we
<br>could evade that issue by only considering =E2=80=9C{=E2=80=9C to start=
an expression
<br>if no statement can start at that place.
<br>
<br>I remember Bjarne discussing this in the early list-init papers, but I
<br>don=E2=80=99t recall the details of the conclusion (I do seem to recall=
that
<br>he right away decided to only allow them on the right hand side of
<br>assignments, when it came to non-initializer contexts).
<br>
<br>My gut feeling is that there isn=E2=80=99t an insurmountable problem wi=
th the
<br>idea though (assuming we allow a leading =E2=80=9C{=E2=80=9C in a state=
ment to always
<br>resolve to a block statement).
<br>---snap---
<br></blockquote><div>=C2=A0</div><div>Yes, that's the point - <b>let l=
eading =E2=80=9C{=E2=80=9C be a block statement as it always was</b>.</div>=
<div><br></div><div><i>In that sense the user will not have to learn someth=
ing new! He already knows '{' does not start an expression!</i></di=
v><div><i><br></i></div><div>It is worth also nothing, the deduction is mor=
e often needed and used on the RHS anyway.</div><div><br></div><div>Users w=
rite more often if(x =3D=3D -1) and if(ptr !=3D 0), then the other way arou=
nd.=C2=A0</div><div>The reverse needs pretty much be trained, for a specifi=
c reason,<i>=C2=A0</i></div><div><i>if someone has the training to reverse =
the args, he'll got used to specify the type anyway!</i></div><div><br>=
</div><div><b>Also</b>, some operations do not even make sense if reversed:=
</div><div><br></div><div><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styled=
-by-prettify">PointList</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> list</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
<br><br></span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
</span><font color=3D"#880000"><span style=3D"color: #800;" class=3D"styled=
-by-prettify">expected and much needed behavior:</span></font><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>list </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span 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: #066;"=
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">-</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// useless anyway:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{-</span><span style=3D=
"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">-</span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> list</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><=
br>Some will argue, this should work, it is not meaningless:</div><div><br>=
</div><div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
-</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">-</span><span style=3D"color: #066;"=
class=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">>></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> list</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan></div></code></div><br>But, seriously, who writes code like that ?!?=C2=
=A0</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/3b50c2a8-8625-43c0-994a-bc6887a0d67c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3b50c2a8-8625-43c0-994a-bc6887a0d67c=
%40isocpp.org</a>.<br />
------=_Part_1_797372141.1474357239126--
------=_Part_0_1969963542.1474357239124--
.