------=_Part_717_1249024990.1425320140925
Content-Type: multipart/alternative;
 boundary="----=_Part_718_710357505.1425320140925"

------=_Part_718_710357505.1425320140925
Content-Type: text/plain; charset=UTF-8

Hello everyone,

I'd like to present a paper that proposes to make if!(condition) valid
syntax meaning the same as if(!(condition)).
https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
Let me know what you think.

Markus

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Hello everyone,<br><br>I'd like to present a paper that pr=
oposes to make if!(condition) valid syntax meaning the same as if(!(conditi=
on)).<br><a href=3D"https://docs.google.com/document/d/15DiMYFCexU-P82mtOPG=
Uis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing">https://docs.google.com/docume=
nt/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing</a><br=
>Let me know what you think.<br><br>Markus<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_718_710357505.1425320140925--
------=_Part_717_1249024990.1425320140925--

.

On Monday 02 March 2015 10:15:40 Markus Grech wrote:
> Hello everyone,
>
> I'd like to present a paper that proposes to make if!(condition) valid
> syntax meaning the same as if(!(condition)).
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC
> -nE/edit?usp=sharing Let me know what you think.

Would I be allowed to use if ~(condition)  or maybe write if -(condition)?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_683_704487674.1425320600144
Content-Type: multipart/alternative;
 boundary="----=_Part_684_1246991007.1425320600144"

------=_Part_684_1246991007.1425320600144
Content-Type: text/plain; charset=UTF-8



On Monday, March 2, 2015 at 7:19:31 PM UTC+1, Thiago Macieira wrote:
>
> On Monday 02 March 2015 10:15:40 Markus Grech wrote:
> > Hello everyone,
> >
> > I'd like to present a paper that proposes to make if!(condition) valid
> > syntax meaning the same as if(!(condition)).
> >
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC
> > -nE/edit?usp=sharing Let me know what you think.
>
> Would I be allowed to use if ~(condition)  or maybe write if -(condition)?
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>
 It is currently not proposed, because I'm not convinced that it is a good
idea to write if(~(condition)). I'm not too attached to that "restriction"
though.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Monday, March 2, 2015 at 7:19:31 PM UTC+1, Thia=
go Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday 02=
 March 2015 10:15:40 Markus Grech wrote:
<br>&gt; Hello everyone,
<br>&gt;=20
<br>&gt; I'd like to present a paper that proposes to make if!(condition) v=
alid
<br>&gt; syntax meaning the same as if(!(condition)).
<br>&gt; <a href=3D"https://docs.google.com/document/d/15DiMYFCexU-P82mtOPG=
Uis9eQxnuE_ocuRdg_1BC" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnu=
E_ocuRdg_1BC';return true;" onclick=3D"this.href=3D'https://docs.google.com=
/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC';return true;">https:=
//docs.google.com/<wbr>document/d/15DiMYFCexU-<wbr>P82mtOPGUis9eQxnuE_ocuRd=
g_1BC</a>
<br>&gt; -nE/edit?usp=3Dsharing Let me know what you think.
<br>
<br>Would I be allowed to use if ~(condition) &nbsp;or maybe write if -(con=
dition)?
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote><div><br>&nbsp;It is currently not proposed, because I'm n=
ot convinced that it is a good idea to write if(~(condition)). I'm not too =
attached to that "restriction" though.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_684_1246991007.1425320600144--
------=_Part_683_704487674.1425320600144--

.

On 2015-03-02 13:15, Markus Grech wrote:
> I'd like to present a paper that proposes to make if!(condition) valid
> syntax meaning the same as if(!(condition)).
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> Let me know what you think.

It's been proposed before and AFAIK didn't go anywhere. At minimum I
would mention newly allowing 'if !(auto value = expr)' as a motivating
case, as, frankly, I see no value in the change otherwise. (In
particular, the bar for making changes to the core language is very
high, and I don't see this being worthwhile.)

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

.

------=_Part_649_748811827.1425320879663
Content-Type: multipart/alternative;
 boundary="----=_Part_650_1726118324.1425320879667"

------=_Part_650_1726118324.1425320879667
Content-Type: text/plain; charset=UTF-8

I did mention that use case in the proposal ;)

On Monday, March 2, 2015 at 7:23:23 PM UTC+1, Matthew Woehlke wrote:
>
> On 2015-03-02 13:15, Markus Grech wrote:
> > I'd like to present a paper that proposes to make if!(condition) valid
> > syntax meaning the same as if(!(condition)).
> >
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> > Let me know what you think.
>
> It's been proposed before and AFAIK didn't go anywhere. At minimum I
> would mention newly allowing 'if !(auto value = expr)' as a motivating
> case, as, frankly, I see no value in the change otherwise. (In
> particular, the bar for making changes to the core language is very
> high, and I don't see this being worthwhile.)
>
> --
> 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 http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I did mention that use case in the proposal ;)<br><br>On M=
onday, March 2, 2015 at 7:23:23 PM UTC+1, Matthew Woehlke wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On 2015-03-02 13:15, Markus Grech wrote:
<br>&gt; I'd like to present a paper that proposes to make if!(condition) v=
alid=20
<br>&gt; syntax meaning the same as if(!(condition)).
<br>&gt; <a href=3D"https://docs.google.com/document/d/15DiMYFCexU-P82mtOPG=
Uis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'https://docs.google.com/document/d/15DiMYF=
CexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;" onc=
lick=3D"this.href=3D'https://docs.google.com/document/d/15DiMYFCexU-P82mtOP=
GUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;">https://docs.go=
ogle.com/<wbr>document/d/15DiMYFCexU-<wbr>P82mtOPGUis9eQxnuE_ocuRdg_1BC-<wb=
r>nE/edit?usp=3Dsharing</a>
<br>&gt; Let me know what you think.
<br>
<br>It's been proposed before and AFAIK didn't go anywhere. At minimum I
<br>would mention newly allowing 'if !(auto value =3D expr)' as a motivatin=
g
<br>case, as, frankly, I see no value in the change otherwise. (In
<br>particular, the bar for making changes to the core language is very
<br>high, and I don't see this being worthwhile.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_650_1726118324.1425320879667--
------=_Part_649_748811827.1425320879663--

.

On Mon, Mar 2, 2015 at 1:27 PM, Markus Grech <markus.grech@gmail.com> wrote:
> I did mention that use case in the proposal ;)
>

Please provide an example as well.

It seems that the syntax you are proposing does not allow alternative
tokens.  I want to write:

  if not (...)

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_750_1763000633.1425321871899
Content-Type: multipart/alternative;
 boundary="----=_Part_751_1919761172.1425321871899"

------=_Part_751_1919761172.1425321871899
Content-Type: text/plain; charset=UTF-8



On Monday, March 2, 2015 at 7:38:46 PM UTC+1, Zhihao Yuan wrote:
>
> On Mon, Mar 2, 2015 at 1:27 PM, Markus Grech <markus...@gmail.com
> <javascript:>> wrote:
> > I did mention that use case in the proposal ;)
> >
>
> Please provide an example as well.
>
Seems like it would be a good idea, I'll add one.


> It seems that the syntax you are proposing does not allow alternative
> tokens.  I want to write:
>
>   if not (...)
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://bit.ly/blog4bsd
>
Correct me if I'm wrong, but as far as I'm concerned, alternative tokens
are replaced in earlier translation stages and thus it would be allowed
with this grammar. I intend for alternative tokens to be allowed.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Monday, March 2, 2015 at 7:38:46 PM UTC+1, Zhih=
ao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Mar 2, 2=
015 at 1:27 PM, Markus Grech &lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"cN3dgxZkt2gJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">markus...@gmail.com</a>&gt; wrote:
<br>&gt; I did mention that use case in the proposal ;)
<br>&gt;
<br>
<br>Please provide an example as well.
<br></blockquote><div>Seems like it would be a good idea, I'll add one. <br=
></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It see=
ms that the syntax you are proposing does not allow alternative
<br>tokens. &nbsp;I want to write:
<br>
<br>&nbsp; if not (...)
<br>
<br>--=20
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA3DF1H_gEgIkwnC=
r7FAkiCyQ';return true;" onclick=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA=
3DF1H_gEgIkwnCr7FAkiCyQ';return true;">http://bit.ly/blog4bsd</a>
<br></blockquote><div>Correct me if I'm wrong, but as far as I'm concerned,=
 alternative tokens are replaced in earlier translation stages and thus it =
would be allowed with this grammar. I intend for alternative tokens to be a=
llowed.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_751_1919761172.1425321871899--
------=_Part_750_1763000633.1425321871899--

.

On 2 March 2015 at 20:38, Zhihao Yuan <zy@miator.net> wrote:
> It seems that the syntax you are proposing does not allow alternative
> tokens.  I want to write:

How so? What in it forbids an alternative token?

Regarding the proposal in general, I neither love it nor hate it. For
many cases,
transforming

if (foogetvalue(something) && bargetvalue(someother))
to
if (getvals(something, someother))
also makes the condition much easier to negate. However, the case for
if (!stream >> x) seems decent. I wouldn't say it's quite worth this
sort of a language
change, so I'm mildly against this change. The implementation and specification
cost is comparatively large for such a small tweak of a 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-03-02 19:15, Markus Grech wrote:
> Hello everyone,
>
> I'd like to present a paper that proposes to make if!(condition) valid
> syntax meaning the same as if(!(condition)).
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> Let me know what you think.
>

Some random thoughts:

While nice and not breaking existing code, the new syntax does introduce
new possibilities for typos - writing "if!(..." when meaning "if(!...".
This is slightly similar to "if(a=b)" vs "if(a==b)".


The if! ... else ... can already be expressed by just interchanging the
statement parts. I often do that, as it seems to avoid a double negation
for the else-part.


Likewise, you might want to spell out why "do ... while!" is better than
introducing a "do ... until" construct. Perhaps using a context
dependent meaning of until (similar to override and final).  :-)


We could also consider what happens if the operator! is overloaded for
some or all of the involved types.


Bo Persson


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-03-02 13:27, Markus Grech wrote:
> On Monday, March 2, 2015 at 7:23:23 PM UTC+1, Matthew Woehlke wrote:
>> On 2015-03-02 13:15, Markus Grech wrote:
>>> I'd like to present a paper that proposes to make if!(condition) valid
>>> syntax meaning the same as if(!(condition)).
>>>
>>> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
>>> Let me know what you think.
>>
>> It's been proposed before and AFAIK didn't go anywhere. At minimum I
>> would mention newly allowing 'if !(auto value = expr)' as a motivating
>> case, as, frankly, I see no value in the change otherwise. (In
>> particular, the bar for making changes to the core language is very
>> high, and I don't see this being worthwhile.)
>
> I did mention that use case in the proposal ;)

I'm not seeing it... either in your Motivation or in your Proposed Text.
(I don't think the grammar changes are sufficient for such use. A
declaration-assignment is not a condition. I am thinking that for such
case to be supported, the change to the grammar of a
declaration-assignment 'if' statement would need to be noted.)

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

.

On Mon, Mar 2, 2015 at 1:44 PM, Markus Grech <markus.grech@gmail.com> wrote:
>>
>>   if not (...)
>
> Correct me if I'm wrong, but as far as I'm concerned, alternative tokens are
> replaced in earlier translation stages and thus it would be allowed with
> this grammar. I intend for alternative tokens to be allowed.

Oh, indeed.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4247_555266736.1425346470466
Content-Type: multipart/alternative;
 boundary="----=_Part_4248_1551585737.1425346470466"

------=_Part_4248_1551585737.1425346470466
Content-Type: text/plain; charset=UTF-8

On Monday, March 2, 2015 at 1:15:41 PM UTC-5, Markus Grech wrote:
>
> Hello everyone,
>
> I'd like to present a paper that proposes to make if!(condition) valid
> syntax meaning the same as if(!(condition)).
>
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> Let me know what you think.
>
> Markus
>

Are keystrokes in such short supply that we need to save them this badly?

This just makes the language wierd. For example, you will need to explain
to someone why this is legal:

if !(foo)

And yet, this is not:

if !foo

Nor is:

if foo

Nor is:

if ~(foo)

See, once you start moving one operator out of the parentheses, you need a
good justification for why we can't move the entire conditional expression
outside of them. Because that's what it looks like you're doing. Or at the
very least, it should extend to all unary operator. Otherwise, it looks
like either a programming error or a language hack.

And C++ has enough language hacks to be going on with...

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, March 2, 2015 at 1:15:41 PM UTC-5, Markus Grech=
 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">Hello =
everyone,<br><br>I'd like to present a paper that proposes to make if!(cond=
ition) valid syntax meaning the same as if(!(condition)).<br><a href=3D"htt=
ps://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-n=
E/edit?usp=3Dsharing" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE=
_ocuRdg_1BC-nE/edit?usp\75sharing';return true;" onclick=3D"this.href=3D'ht=
tps://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-=
nE/edit?usp\75sharing';return true;">https://docs.google.com/<wbr>document/=
d/15DiMYFCexU-<wbr>P82mtOPGUis9eQxnuE_ocuRdg_1BC-<wbr>nE/edit?usp=3Dsharing=
</a><br>Let me know what you think.<br><br>Markus<br></div></blockquote><di=
v><br>Are keystrokes in such short supply that we need to save them this ba=
dly?<br><br>This just makes the language wierd. For example, you will need =
to explain to someone why this is legal:<br><br>if !(foo)<br><br>And yet, t=
his is not:<br><br>if !foo<br><br>Nor is:<br><br>if foo<br><br>Nor is:<br><=
br>if ~(foo)<br><br>See, once you start moving one operator out of the pare=
ntheses, you need a good justification for why we can't move the entire con=
ditional expression outside of them. Because that's what it looks like you'=
re doing. Or at the very least, it should extend to all unary operator. Oth=
erwise, it looks like either a programming error or a language hack.<br><br=
>And C++ has enough language hacks to be going on with...<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4248_1551585737.1425346470466--
------=_Part_4247_555266736.1425346470466--

.

------=_Part_4121_207944693.1425367085510
Content-Type: multipart/alternative;
 boundary="----=_Part_4122_970561582.1425367085510"

------=_Part_4122_970561582.1425367085510
Content-Type: text/plain; charset=UTF-8

On Tuesday, March 3, 2015 at 2:34:30 AM UTC+1, Nicol Bolas wrote:
>
> On Monday, March 2, 2015 at 1:15:41 PM UTC-5, Markus Grech wrote:
>>
>> Hello everyone,
>>
>> I'd like to present a paper that proposes to make if!(condition) valid
>> syntax meaning the same as if(!(condition)).
>>
>> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
>> Let me know what you think.
>>
>> Markus
>>
>
> Are keystrokes in such short supply that we need to save them this badly?
>
It's not about saving keystrokes. It's about increasing factorability. Have
you never written a piece of code and then went "Oh, I can improve this by
negating this condition and moving these bits around" or similar? I'd say
that's pretty common and a language should make it easy to do such changes.
The parenthesis are just syntactic baggage without any value.


> This just makes the language wierd. For example, you will need to explain
> to someone why this is legal:
>
> if !(foo)
>
> And yet, this is not:
>
> if !foo
>
> Nor is:
>
> if foo
>
> Nor is:
>
> if ~(foo)
>
> See, once you start moving one operator out of the parentheses, you need a
> good justification for why we can't move the entire conditional expression
> outside of them. Because that's what it looks like you're doing. Or at the
> very least, it should extend to all unary operator. Otherwise, it looks
> like either a programming error or a language hack.
>
> And C++ has enough language hacks to be going on with...
>
conditions are fundamentally of boolean nature. I don't see why it would be
a good idea to support for example increment. The point with factorability
that I mentioned above also doesn't apply to unary operators.

And if we're going to allow unary operators (btw, what about postfix:
if(foo)[0] anyone?), another question becomes why we shouldn't allow
multiple operators. And then it just becomes an even bigger mess for
something that is a rather simple proposal.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Tuesday, March 3, 2015 at 2:34:30 AM UTC+1, Nicol Bolas=
 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">On Mon=
day, March 2, 2015 at 1:15:41 PM UTC-5, Markus Grech wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">Hello everyone,<br><br>I'd like to=
 present a paper that proposes to make if!(condition) valid syntax meaning =
the same as if(!(condition)).<br><a href=3D"https://docs.google.com/documen=
t/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing" rel=3D=
"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://docs.googl=
e.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sh=
aring';return true;" onclick=3D"this.href=3D'https://docs.google.com/docume=
nt/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';retur=
n true;">https://docs.google.com/<wbr>document/d/15DiMYFCexU-<wbr>P82mtOPGU=
is9eQxnuE_ocuRdg_1BC-<wbr>nE/edit?usp=3Dsharing</a><br>Let me know what you=
 think.<br><br>Markus<br></div></blockquote><div><br>Are keystrokes in such=
 short supply that we need to save them this badly?<br></div></div></blockq=
uote><div>It's not about saving keystrokes. It's about increasing factorabi=
lity. Have you never written a piece of code and then went "Oh, I can impro=
ve this by negating this condition and moving these bits around" or similar=
? I'd say that's pretty common and a language should make it easy to do suc=
h changes. The parenthesis are just syntactic baggage without any value.</d=
iv><div>&nbsp;</div><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"><div>This just makes the language wierd. For example, you will nee=
d to explain to someone why this is legal:<br><br>if !(foo)<br><br>And yet,=
 this is not:<br><br>if !foo<br><br>Nor is:<br><br>if foo<br><br>Nor is:<br=
><br>if ~(foo)<br><br>See, once you start moving one operator out of the pa=
rentheses, you need a good justification for why we can't move the entire c=
onditional expression outside of them. Because that's what it looks like yo=
u're doing. Or at the very least, it should extend to all unary operator. O=
therwise, it looks like either a programming error or a language hack.<br><=
br>And C++ has enough language hacks to be going on with...<br></div></div>=
</blockquote><div>conditions are fundamentally of boolean nature. I don't s=
ee why it would be a good idea to support for example increment. The point =
with factorability that I mentioned above also doesn't apply to unary opera=
tors.</div><div><br></div><div>And if we're going to allow unary operators =
(btw, what about postfix: if(foo)[0] anyone?), another question becomes why=
 we shouldn't allow multiple operators. And then it just becomes an even bi=
gger mess for something that is a rather simple proposal.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4122_970561582.1425367085510--
------=_Part_4121_207944693.1425367085510--

.

------=_Part_4537_101394677.1425369863530
Content-Type: multipart/alternative;
 boundary="----=_Part_4538_1185804268.1425369863530"

------=_Part_4538_1185804268.1425369863530
Content-Type: text/plain; charset=UTF-8

On Monday, March 2, 2015 at 7:55:55 PM UTC+1, Bo Persson wrote:
>
> On 2015-03-02 19:15, Markus Grech wrote:
> > Hello everyone,
> >
> > I'd like to present a paper that proposes to make if!(condition) valid
> > syntax meaning the same as if(!(condition)).
> >
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> > Let me know what you think.
> >
>
> Some random thoughts:
>
> While nice and not breaking existing code, the new syntax does introduce
> new possibilities for typos - writing "if!(..." when meaning "if(!...".
> This is slightly similar to "if(a=b)" vs "if(a==b)".
>
No risk no fun? Fair point I guess, but what language feature doesn't add
potential for typos?

>
> The if! ... else ... can already be expressed by just interchanging the
> statement parts. I often do that, as it seems to avoid a double negation
> for the else-part.
>
 Well, I agree that double negation should be avoided. But if we add the
feature to if, it should also apply to if else.


> Likewise, you might want to spell out why "do ... while!" is better than
> introducing a "do ... until" construct. Perhaps using a context
> dependent meaning of until (similar to override and final).  :-)
>
Probably along the lines of "Why introduce a new keyword when we can reuse
existing constructs in the language?". I'll add it, thanks.


> We could also consider what happens if the operator! is overloaded for
> some or all of the involved types.
>
This is actually a very good point I didn't consider. I will change the
feature to be specified in terms of a transformation which should make it
clear what should happen in that case.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, March 2, 2015 at 7:55:55 PM UTC+1, Bo Persson w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-03-02 19:15, Mark=
us Grech wrote:
<br>&gt; Hello everyone,
<br>&gt;
<br>&gt; I'd like to present a paper that proposes to make if!(condition) v=
alid
<br>&gt; syntax meaning the same as if(!(condition)).
<br>&gt; <a href=3D"https://docs.google.com/document/d/15DiMYFCexU-P82mtOPG=
Uis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing" target=3D"_blank" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'https://docs.google.com/document/d/15DiMYF=
CexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;" onc=
lick=3D"this.href=3D'https://docs.google.com/document/d/15DiMYFCexU-P82mtOP=
GUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;">https://docs.go=
ogle.com/<wbr>document/d/15DiMYFCexU-<wbr>P82mtOPGUis9eQxnuE_ocuRdg_1BC-<wb=
r>nE/edit?usp=3Dsharing</a>
<br>&gt; Let me know what you think.
<br>&gt;
<br>
<br>Some random thoughts:
<br>
<br>While nice and not breaking existing code, the new syntax does introduc=
e=20
<br>new possibilities for typos - writing "if!(..." when meaning "if(!...".=
=20
<br>This is slightly similar to "if(a=3Db)" vs "if(a=3D=3Db)".
<br></blockquote><div>No risk no fun? Fair point I guess, but what language=
 feature doesn't add potential for typos?</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<br>The if! ... else ... can already be expressed by just interchanging the=
=20
<br>statement parts. I often do that, as it seems to avoid a double negatio=
n=20
<br>for the else-part.
<br></blockquote><div>&nbsp;Well, I agree that double negation should be av=
oided. But if we add the feature to if, it should also apply to if else.</d=
iv><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Likewise, =
you might want to spell out why "do ... while!" is better than=20
<br>introducing a "do ... until" construct. Perhaps using a context=20
<br>dependent meaning of until (similar to override and final). &nbsp;:-)
<br></blockquote><div>Probably along the lines of "Why introduce a new keyw=
ord when we can reuse existing constructs in the language?". I'll add it, t=
hanks.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">W=
e could also consider what happens if the operator! is overloaded for=20
<br>some or all of the involved types.
<br></blockquote><div>This is actually a very good point I didn't consider.=
 I will change the feature to be specified in terms of a transformation whi=
ch should make it clear what should happen in that case.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4538_1185804268.1425369863530--
------=_Part_4537_101394677.1425369863530--

.

--089e01493d9e72053405105dfab0
Content-Type: text/plain; charset=UTF-8

Am 02.03.2015 19:15 schrieb "Markus Grech" <markus.grech@gmail.com>:
>
> Hello everyone,
>
> I'd like to present a paper that proposes to make if!(condition) valid
syntax meaning the same as if(!(condition)).
>
https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> Let me know what you think.
>

What about making the parens around the expression in "if" optional? Then
this is possible naturally.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01493d9e72053405105dfab0
Content-Type: text/html; charset=UTF-8

<p dir="ltr"><br>
Am 02.03.2015 19:15 schrieb &quot;Markus Grech&quot; &lt;<a href="mailto:markus.grech@gmail.com">markus.grech@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; Hello everyone,<br>
&gt;<br>
&gt; I&#39;d like to present a paper that proposes to make if!(condition) valid syntax meaning the same as if(!(condition)).<br>
&gt; <a href="https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing">https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing</a><br>
&gt; Let me know what you think.<br>
&gt;</p>
<p dir="ltr">What about making the parens around the expression in &quot;if&quot; optional? Then this is possible naturally.</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--089e01493d9e72053405105dfab0--

.

------=_Part_2189_1023676885.1425371901091
Content-Type: multipart/alternative;
 boundary="----=_Part_2190_1445910078.1425371901092"

------=_Part_2190_1445910078.1425371901092
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wrote:
>
>
> Am 02.03.2015 19:15 schrieb "Markus Grech" <markus...@gmail.com
> <javascript:>>:
> >
> > Hello everyone,
> >
> > I'd like to present a paper that proposes to make if!(condition) valid
> syntax meaning the same as if(!(condition)).
> >
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> > Let me know what you think.
> >
>
> What about making the parens around the expression in "if" optional? Then
> this is possible naturally.
>
I fear that would introduce too many ambiguities. How would you determine
the end of an expression? For example:
if a
        -b
Would that mean
if(a)
        -b
or
if(a-b)
        ...
etc.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Joh=
annes Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"l=
tr"><br>
Am 02.03.2015 19:15 schrieb "Markus Grech" &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"mVrz3RXUFmYJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">markus...@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; Hello everyone,<br>
&gt;<br>
&gt; I'd like to present a paper that proposes to make if!(condition) valid=
 syntax meaning the same as if(!(condition)).<br>
&gt; <a href=3D"https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9=
eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing" target=3D"_blank" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D'https://docs.google.com/document/d/15DiMYFCexU=
-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;" onclick=
=3D"this.href=3D'https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis=
9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;">https://docs.google=
..com/<wbr>document/d/15DiMYFCexU-<wbr>P82mtOPGUis9eQxnuE_ocuRdg_1BC-<wbr>nE=
/edit?usp=3Dsharing</a><br>
&gt; Let me know what you think.<br>
&gt;</p>
<p dir=3D"ltr">What about making the parens around the expression in "if" o=
ptional? Then this is possible naturally.</p></blockquote><div>I fear that =
would introduce too many ambiguities. How would you determine the end of an=
 expression? For example:</div><div><div class=3D"prettyprint" style=3D"bor=
der: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color:=
 rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettypr=
int"><div style=3D"background-color: rgb(255, 255, 255);"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> a<br></span><font color=3D"#666600" face=
=3D"Arial, Helvetica, sans-serif"><span class=3D"Apple-tab-span" style=3D"w=
hite-space: pre;"><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>&nbsp; &nbsp; &nbsp; &nbsp; </span></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">-</span></font><span style=3D"color: #000;" class=
=3D"styled-by-prettify">b</span></div></div></code></div></div><div>Would t=
hat mean</div><div><div class=3D"prettyprint" style=3D"border: 1px solid rg=
b(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: rgb(0, 0, 0); font-family: Ari=
al, Helvetica, sans-serif; white-space: pre; background-color: rgb(255, 255=
, 255);"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &=
nbsp; &nbsp; &nbsp; </span></span><span class=3D"Apple-tab-span" style=3D"w=
hite-space: pre;"><font color=3D"#666600"><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">-</span></font><span style=3D"color: #000;" class=
=3D"styled-by-prettify">b</span></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div>or</div><div><div cla=
ss=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap=
: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">-</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
></font><span style=3D"color: rgb(0, 0, 0); font-family: Arial, Helvetica, =
sans-serif; white-space: pre; background-color: rgb(255, 255, 255);"><span =
style=3D"color: #000;" class=3D"styled-by-prettify">&nbsp; &nbsp; &nbsp; &n=
bsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">...</=
span></span></div></code></div>etc.<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2190_1445910078.1425371901092--
------=_Part_2189_1023676885.1425371901091--

.

--047d7b3433dac2ad8705105e4ec6
Content-Type: text/plain; charset=UTF-8

Am 03.03.2015 09:38 schrieb "Markus Grech" <markus.grech@gmail.com>:
>
>
>
> On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wrote:
>>
>>
>> Am 02.03.2015 19:15 schrieb "Markus Grech" <markus...@gmail.com>:
>>
>> >
>> > Hello everyone,
>> >
>> > I'd like to present a paper that proposes to make if!(condition) valid
syntax meaning the same as if(!(condition)).
>> >
https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
>> > Let me know what you think.
>> >
>>
>> What about making the parens around the expression in "if" optional?
Then this is possible naturally.
>
> I fear that would introduce too many ambiguities. How would you determine
the end of an expression? For example:
> if a
>         -b
> Would that mean
> if(a)
>         -b
> or
> if(a-b)
>         ...
> etc.
>

Use the same rule as "sizeof expr": The longest sequence that could
possibly be an expression is taken to be the expression.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr">Am 03.03.2015 09:38 schrieb &quot;Markus Grech&quot; &lt;<a =
href=3D"mailto:markus.grech@gmail.com">markus.grech@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wrote:<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Am 02.03.2015 19:15 schrieb &quot;Markus Grech&quot; &lt;<a href=
=3D"mailto:markus...@gmail.com">markus...@gmail.com</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hello everyone,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I&#39;d like to present a paper that proposes to make if!(con=
dition) valid syntax meaning the same as if(!(condition)).<br>
&gt;&gt; &gt; <a href=3D"https://docs.google.com/document/d/15DiMYFCexU-P82=
mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing">https://docs.google.com/d=
ocument/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing</=
a><br>
&gt;&gt; &gt; Let me know what you think.<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; What about making the parens around the expression in &quot;if&quo=
t; optional? Then this is possible naturally.<br>
&gt;<br>
&gt; I fear that would introduce too many ambiguities. How would you determ=
ine the end of an expression? For example:<br>
&gt; if a<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 -b<br>
&gt; Would that mean<br>
&gt; if(a)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 -b<br>
&gt; or<br>
&gt; if(a-b)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>
&gt; etc.<br>
&gt;</p>
<p dir=3D"ltr">Use the same rule as &quot;sizeof expr&quot;: The longest se=
quence that could possibly be an expression is taken to be the expression.<=
/p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3433dac2ad8705105e4ec6--

.

--089e012297103158fc05105e5f1a
Content-Type: text/plain; charset=UTF-8

Am 03.03.2015 09:41 schrieb "Johannes Schaub" <
schaub.johannes@googlemail.com>:
>
> Am 03.03.2015 09:38 schrieb "Markus Grech" <markus.grech@gmail.com>:
>
> >
> >
> >
> > On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wrote:
> >>
> >>
> >> Am 02.03.2015 19:15 schrieb "Markus Grech" <markus...@gmail.com>:
> >>
> >> >
> >> > Hello everyone,
> >> >
> >> > I'd like to present a paper that proposes to make if!(condition)
valid syntax meaning the same as if(!(condition)).
> >> >
https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> >> > Let me know what you think.
> >> >
> >>
> >> What about making the parens around the expression in "if" optional?
Then this is possible naturally.
> >
> > I fear that would introduce too many ambiguities. How would you
determine the end of an expression? For example:
> > if a
> >         -b
> > Would that mean
> > if(a)
> >         -b
> > or
> > if(a-b)
> >         ...
> > etc.
> >
>
> Use the same rule as "sizeof expr": The longest sequence that could
possibly be an expression is taken to be the expression.

Actually I am not sure whether we have this rule for sizeof or whether it
simply only accepts unary expressions for which no ambiguity could arise.

The same could be done for if. (...) is an unary expression so it would be
backwards compatible afaics.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<p dir=3D"ltr"><br>
Am 03.03.2015 09:41 schrieb &quot;Johannes Schaub&quot; &lt;<a href=3D"mail=
to:schaub.johannes@googlemail.com">schaub.johannes@googlemail.com</a>&gt;:<=
br>
&gt;<br>
&gt; Am 03.03.2015 09:38 schrieb &quot;Markus Grech&quot; &lt;<a href=3D"ma=
ilto:markus.grech@gmail.com">markus.grech@gmail.com</a>&gt;:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wr=
ote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Am 02.03.2015 19:15 schrieb &quot;Markus Grech&quot; &lt;<a h=
ref=3D"mailto:markus...@gmail.com">markus...@gmail.com</a>&gt;:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; Hello everyone,<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; I&#39;d like to present a paper that proposes to make if=
!(condition) valid syntax meaning the same as if(!(condition)).<br>
&gt; &gt;&gt; &gt; <a href=3D"https://docs.google.com/document/d/15DiMYFCex=
U-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing">https://docs.google.=
com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dshar=
ing</a><br>
&gt; &gt;&gt; &gt; Let me know what you think.<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; What about making the parens around the expression in &quot;i=
f&quot; optional? Then this is possible naturally.<br>
&gt; &gt;<br>
&gt; &gt; I fear that would introduce too many ambiguities. How would you d=
etermine the end of an expression? For example:<br>
&gt; &gt; if a<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 -b<br>
&gt; &gt; Would that mean<br>
&gt; &gt; if(a)<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 -b<br>
&gt; &gt; or<br>
&gt; &gt; if(a-b)<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>
&gt; &gt; etc.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Use the same rule as &quot;sizeof expr&quot;: The longest sequence tha=
t could possibly be an expression is taken to be the expression.</p>
<p dir=3D"ltr">Actually I am not sure whether we have this rule for sizeof =
or whether it simply only accepts unary expressions for which no ambiguity =
could arise. </p>
<p dir=3D"ltr">The same could be done for if. (...) is an unary expression =
so it would be backwards compatible afaics.</p>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e012297103158fc05105e5f1a--

.

------=_Part_33_124430011.1425373285133
Content-Type: multipart/alternative;
 boundary="----=_Part_34_1793606346.1425373285134"

------=_Part_34_1793606346.1425373285134
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 3, 2015 at 9:42:03 AM UTC+1, Johannes Schaub wrote:
>
> Am 03.03.2015 09:38 schrieb "Markus Grech" <markus...@gmail.com
> <javascript:>>:
> >
> >
> >
> > On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wrote:
> >>
> >>
> >> Am 02.03.2015 19:15 schrieb "Markus Grech" <markus...@gmail.com>:
> >>
> >> >
> >> > Hello everyone,
> >> >
> >> > I'd like to present a paper that proposes to make if!(condition)
> valid syntax meaning the same as if(!(condition)).
> >> >
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> >> > Let me know what you think.
> >> >
> >>
> >> What about making the parens around the expression in "if" optional?
> Then this is possible naturally.
> >
> > I fear that would introduce too many ambiguities. How would you
> determine the end of an expression? For example:
> > if a
> >         -b
> > Would that mean
> > if(a)
> >         -b
> > or
> > if(a-b)
> >         ...
> > etc.
> >
>
> Use the same rule as "sizeof expr": The longest sequence that could
> possibly be an expression is taken to be the expression.
>
Hmm, with that rule it might very well be doable. What do the others think
about just removing the parentheses entirely?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, March 3, 2015 at 9:42:03 AM UTC+1, Joh=
annes Schaub wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"l=
tr">Am 03.03.2015 09:38 schrieb "Markus Grech" &lt;<a href=3D"javascript:" =
target=3D"_blank" gdf-obfuscated-mailto=3D"O80dFYmhHHsJ" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">markus...@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wrote:<=
br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Am 02.03.2015 19:15 schrieb "Markus Grech" &lt;<a>markus...@gmail.=
com</a>&gt;:<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Hello everyone,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I'd like to present a paper that proposes to make if!(conditi=
on) valid syntax meaning the same as if(!(condition)).<br>
&gt;&gt; &gt; <a href=3D"https://docs.google.com/document/d/15DiMYFCexU-P82=
mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'https://docs.google.com/document/d/15=
DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;=
" onclick=3D"this.href=3D'https://docs.google.com/document/d/15DiMYFCexU-P8=
2mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75sharing';return true;">https://do=
cs.google.com/<wbr>document/d/15DiMYFCexU-<wbr>P82mtOPGUis9eQxnuE_ocuRdg_1B=
C-<wbr>nE/edit?usp=3Dsharing</a><br>
&gt;&gt; &gt; Let me know what you think.<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; What about making the parens around the expression in "if" optiona=
l? Then this is possible naturally.<br>
&gt;<br>
&gt; I fear that would introduce too many ambiguities. How would you determ=
ine the end of an expression? For example:<br>
&gt; if a<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; -b<br>
&gt; Would that mean<br>
&gt; if(a)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; -b<br>
&gt; or<br>
&gt; if(a-b)<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; ...<br>
&gt; etc.<br>
&gt;</p>
<p dir=3D"ltr">Use the same rule as "sizeof expr": The longest sequence tha=
t could possibly be an expression is taken to be the expression.</p></block=
quote><div>Hmm, with that rule it might very well be doable. What do the ot=
hers think about just removing the parentheses entirely?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_34_1793606346.1425373285134--
------=_Part_33_124430011.1425373285133--

.

That would cause an ambiguity with a currently valid statement - e.g.
if (a) -b

On 3/3/15, Markus Grech <markus.grech@gmail.com> wrote:
>
>
> On Tuesday, March 3, 2015 at 9:42:03 AM UTC+1, Johannes Schaub wrote:
>>
>> Am 03.03.2015 09:38 schrieb "Markus Grech" <markus...@gmail.com
>> <javascript:>>:
>> >
>> >
>> >
>> > On Tuesday, March 3, 2015 at 9:18:36 AM UTC+1, Johannes Schaub wrote:
>> >>
>> >>
>> >> Am 02.03.2015 19:15 schrieb "Markus Grech" <markus...@gmail.com>:
>> >>
>> >> >
>> >> > Hello everyone,
>> >> >
>> >> > I'd like to present a paper that proposes to make if!(condition)
>> valid syntax meaning the same as if(!(condition)).
>> >> >
>> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
>> >> > Let me know what you think.
>> >> >
>> >>
>> >> What about making the parens around the expression in "if" optional?
>> Then this is possible naturally.
>> >
>> > I fear that would introduce too many ambiguities. How would you
>> determine the end of an expression? For example:
>> > if a
>> >         -b
>> > Would that mean
>> > if(a)
>> >         -b
>> > or
>> > if(a-b)
>> >         ...
>> > etc.
>> >
>>
>> Use the same rule as "sizeof expr": The longest sequence that could
>> possibly be an expression is taken to be the expression.
>>
> Hmm, with that rule it might very well be doable. What do the others think
> about just removing the parentheses entirely?
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 3 March 2015 at 11:01, Markus Grech <markus.grech@gmail.com> wrote:
> Hmm, with that rule it might very well be doable. What do the others think
> about just removing the parentheses entirely?


I got the impression that the motivation for the proposal was to make
reading and writing negated
if-conditions easier. Removing the parens goes into the opposite
direction. Chances that
such a proposal will survive committee scrutiny are in the
snowball-in-hell category.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

> I'd like to present a paper that proposes to make if!(condition) valid=20
> syntax meaning the same as if(!(condition)).

In fact you reinvented "unless" statement which can be found in Perl
(and AFAIR in Ruby too). In Perl I like that statement a lot, especially
its trailing form which is useful then the action is short and clear,
but inherently optional, like that:

    print "Applying patches..." unless $quiet;
    apply_patch($patch1);
    apply_patch($patch2);

I don't believe C++ will ever have trailing "if" and "unless"
statements, so introducing only leading "unless" (you call it "if!")
doesn't bring any significant advantages. In Perl I've almost never can
see leading "unless" too.

Anyway, despite your proposal is going to make the language less
consistent and I you may be sure it won't be adopted these days, I like
it. Those (!(...)) are real pain sometimes, they ruin the whole code
appearance. When I encounter such a case, I either rewrite logical
expression from scratch, or extract local variable (preferably, local
constant) and have to carefully prof-read the code in order not to make
a silly error. I can easily remember a dozen of times I wanted "unless"
to be there in C++.

=E2=80=94=E2=80=94=E2=80=94 Pavel Kretov.

--=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 http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2015-03-03 03:04, Markus Grech wrote:
> On Monday, March 2, 2015 at 7:55:55 PM UTC+1, Bo Persson wrote:
>> Likewise, you might want to spell out why "do ... while!" is better than
>> introducing a "do ... until" construct. Perhaps using a context
>> dependent meaning of until (similar to override and final).  :-)
>
> Probably along the lines of "Why introduce a new keyword when we can reuse
> existing constructs in the language?". I'll add it, thanks.

Also, FWIW, *if* this were accepted (and I still think that's a very big
"if"), someone that wants to use 'do ... until' could always '#define
until while!'. (Which effectively makes 'until' a keyword and prevents
it from being used in any other context, but since it's opt-in, we're
not breaking things by standard.)

>> We could also consider what happens if the operator! is overloaded for
>> some or all of the involved types.

Hmm... well you could either say that 'if!' always uses the build-in
operator!, or that 'if!(expr)' is always semantically equivalent to
'if(!(expr))'. The former might actually be a useful rationale for
having the feature in the first place.

In any case, it only matters if typeof(expr) != bool.

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

.

On Tuesday 03 March 2015 10:49:23 Matthew Woehlke wrote:
> Also, FWIW, *if* this were accepted (and I still think that's a very big
> "if"), someone that wants to use 'do ... until' could always '#define
> until while!'. (Which effectively makes 'until' a keyword and prevents
> it from being used in any other context, but since it's opt-in, we're
> not breaking things by standard.)

And #define unless if !

Make C++ more like Perl.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Of course, you can currently do:

#define until(X) while (!(X))

and

#define unless(X) if(!(X))

On 3/3/15, Thiago Macieira <thiago@macieira.org> wrote:
> On Tuesday 03 March 2015 10:49:23 Matthew Woehlke wrote:
>> Also, FWIW, *if* this were accepted (and I still think that's a very big
>> "if"), someone that wants to use 'do ... until' could always '#define
>> until while!'. (Which effectively makes 'until' a keyword and prevents
>> it from being used in any other context, but since it's opt-in, we're
>> not breaking things by standard.)
>
> And #define unless if !
>
> Make C++ more like Perl.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1090_237392266.1427753742243
Content-Type: multipart/alternative;
 boundary="----=_Part_1091_1974682183.1427753742243"

------=_Part_1091_1974682183.1427753742243
Content-Type: text/plain; charset=UTF-8


From doc > Syntactic shortcut

Actually: Syntactic sugar.



On Monday, March 2, 2015 at 7:15:41 PM UTC+1, Markus Grech wrote:

> Hello everyone,
>
> I'd like to present a paper that proposes to make if!(condition) valid
> syntax meaning the same as if(!(condition)).
>
> https://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=sharing
> Let me know what you think.
>
> Markus
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div><br></div><div><span id=3D"docs-internal-guid-a80230f=
f-6cbe-f489-fae4-c837b975ed22" style=3D"color: rgb(0, 0, 0); font-family: A=
rial; font-size: 15px; font-style: normal; font-variant: normal; font-weigh=
t: normal; text-decoration: none; vertical-align: baseline; background-colo=
r: transparent;">From doc &gt; Syntactic shortcut</span></div><div><span st=
yle=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-style=
: normal; font-variant: normal; font-weight: normal; text-decoration: none;=
 vertical-align: baseline; background-color: transparent;"><br></span></div=
><div><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15=
px; font-style: normal; font-variant: normal; font-weight: normal; text-dec=
oration: none; vertical-align: baseline; background-color: transparent;">Ac=
tually: Syntactic sugar.&nbsp;</span></div><div><span style=3D"color: rgb(0=
, 0, 0); font-family: Arial; font-size: 15px; font-style: normal; font-vari=
ant: normal; font-weight: normal; text-decoration: none; vertical-align: ba=
seline; background-color: transparent;"><br></span></div><div><br></div><di=
v><br>On Monday, March 2, 2015 at 7:15:41 PM UTC+1, Markus Grech wrote:</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><div dir=3D"ltr">Hello everyone,<br><br>I'd =
like to present a paper that proposes to make if!(condition) valid syntax m=
eaning the same as if(!(condition)).<br><a onmousedown=3D"this.href=3D'http=
s://docs.google.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE=
/edit?usp\75sharing';return true;" onclick=3D"this.href=3D'https://docs.goo=
gle.com/document/d/15DiMYFCexU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp\75=
sharing';return true;" href=3D"https://docs.google.com/document/d/15DiMYFCe=
xU-P82mtOPGUis9eQxnuE_ocuRdg_1BC-nE/edit?usp=3Dsharing" target=3D"_blank" r=
el=3D"nofollow">https://docs.google.com/<wbr>document/d/15DiMYFCexU-<wbr>P8=
2mtOPGUis9eQxnuE_ocuRdg_1BC-<wbr>nE/edit?usp=3Dsharing</a><br>Let me know w=
hat you think.<br><br>Markus<br></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1091_1974682183.1427753742243--
------=_Part_1090_237392266.1427753742243--

.