------=_Part_745_25840571.1359496290131
Content-Type: text/plain; charset=ISO-8859-1

Allow
if ! ( expression )
and
if not ( expression )
syntax to negate the expression.

Rationale: To negate the expression of an if-statement the expression needs
to be surrounded by parentheses:

if ( ! ( expression ) )

By the above extension the parentheses can be omitted. Other languages have
an unless keyword for this regularly occurring situation.

--

---
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/?hl=en.



------=_Part_745_25840571.1359496290131
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Allow&nbsp;<div>if ! ( expression )&nbsp;<br></div><div><div>and</div><div>=
if not ( expression )</div><div>syntax to negate the expression.</div><div>=
<br></div><div>Rationale: To negate the expression of an if-statement the e=
xpression needs to be surrounded by parentheses:</div><div><br></div><div>i=
f ( ! ( expression ) ) &nbsp;</div></div><div><br></div><div>By the above e=
xtension the parentheses can be omitted. Other languages have an unless key=
word for this regularly occurring situation.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_745_25840571.1359496290131--

.

------=_Part_2007_14706367.1359536807118
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Why don't you define a macro:

#define UNLESS(cond) if(cond){}else

It gives a quite reasonable behavior:

UNLESS (auto p =3D get_ptr()) ...




W dniu wtorek, 29 stycznia 2013 22:51:30 UTC+1 u=BFytkownik Hanspeter=20
Bieri-Ineichen napisa=B3:
>
> Allow=20
> if ! ( expression )=20
> and
> if not ( expression )
> syntax to negate the expression.
>
> Rationale: To negate the expression of an if-statement the expression=20
> needs to be surrounded by parentheses:
>
> if ( ! ( expression ) ) =20
>
> By the above extension the parentheses can be omitted. Other languages=20
> have an unless keyword for this regularly occurring situation.
>

--=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/?hl=3Den.



------=_Part_2007_14706367.1359536807118
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Why don't you define a macro:<br><br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">#define</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> UNLESS</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">cond</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">cond</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">){}</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">else</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span></div></code></div><br>It gives a qu=
ite reasonable behavior:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify">UNLESS </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> get_ptr</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">())</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br><=
br><br><br>W dniu wtorek, 29 stycznia 2013 22:51:30 UTC+1 u=BFytkownik Hans=
peter Bieri-Ineichen napisa=B3:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>Allow&nbsp;<div>if ! ( expression )&nbsp;<br></div><div><div>and</div><div=
>if not ( expression )</div><div>syntax to negate the expression.</div><div=
><br></div><div>Rationale: To negate the expression of an if-statement the =
expression needs to be surrounded by parentheses:</div><div><br></div><div>=
if ( ! ( expression ) ) &nbsp;</div></div><div><br></div><div>By the above =
extension the parentheses can be omitted. Other languages have an unless ke=
yword for this regularly occurring situation.</div></blockquote>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2007_14706367.1359536807118--

.

------=_Part_619_25007695.1359543623475
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 30, 2013 10:06:47 AM UTC+1, Andrzej Krzemie=C5=84ski =
wrote:

> Why don't you define a macro:
>
> #define UNLESS(cond) if(cond){}else
>
> It gives a quite reasonable behavior:
>
> UNLESS (auto p =3D get_ptr()) ...
>
> Macros are bad and the example doesn't make sense, as the code will only=
=20
be executed if !p. In that case there's no need to store p and you could=20
just use if (!get_ptr())=20

--=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/?hl=3Den.



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

On Wednesday, January 30, 2013 10:06:47 AM UTC+1, Andrzej Krzemie=C5=84ski =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Why don't you define=
 a macro:<br><br><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wor=
d"><code><div><span style=3D"color:#800">#define</span><span style=3D"color=
:#000"> UNLESS</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">cond</span><span style=3D"color:#660">)</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">if</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">cond</span><span style=3D"color:#660">=
){}</span><span style=3D"color:#008">else</span><span style=3D"color:#000">=
<br></span></div></code></div><br>It gives a quite reasonable behavior:<br>=
<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,18=
7,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><div=
><span style=3D"color:#000">UNLESS </span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#008">auto</span><span style=3D"color:#000"> p </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> get_ptr<=
/span><span style=3D"color:#660">())</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">...</span><span style=3D"color:#000"><br></sp=
an></div></code></div><br></blockquote><div>Macros are bad and the example =
doesn't make sense, as the code will only be executed if !p. In that case t=
here's no need to store p and you could just use if (!get_ptr())&nbsp;</div=
>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_619_25007695.1359543623475--

.

------=_Part_206_10253788.1359544573209
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, January 30, 2013 10:06:47 AM UTC+1, Andrzej Krzemie=C5=84ski =
wrote:
>
> Why don't you define a macro:
>
> #define UNLESS(cond) if(cond){}else
>
> It gives a quite reasonable behavior:
>
> UNLESS (auto p =3D get_ptr()) ...
>
>
That won't work if you also want to use 'else'.

--=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/?hl=3Den.



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

<br><br>On Wednesday, January 30, 2013 10:06:47 AM UTC+1, Andrzej Krzemie=
=C5=84ski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Why don't you =
define a macro:<br><br><div style=3D"background-color:rgb(250,250,250);bord=
er-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:bre=
ak-word"><code><div><span style=3D"color:#800">#define</span><span style=3D=
"color:#000"> UNLESS</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">cond</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">if</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">cond</span><span style=3D"co=
lor:#660">){}</span><span style=3D"color:#008">else</span><span style=3D"co=
lor:#000"><br></span></div></code></div><br>It gives a quite reasonable beh=
avior:<br><br><div 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><div><span style=3D"color:#000">UNLESS </span><span style=3D"color:#6=
60">(</span><span style=3D"color:#008">auto</span><span style=3D"color:#000=
"> p </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"=
> get_ptr</span><span style=3D"color:#660">())</span><span style=3D"color:#=
000"> </span><span style=3D"color:#660">...</span><span style=3D"color:#000=
"><br></span></div></code></div><br></blockquote><div><br></div><div>That w=
on't work if you also want to use 'else'.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_206_10253788.1359544573209--

.

------=_Part_107_1921670.1359547007209
Content-Type: text/plain; charset=ISO-8859-1

There are nine billion reasons not to define a macro. Why you wouldn't use
a template function with a lambda, IDK, but not using a macro is kinda a
given.

--

---
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/?hl=en.



------=_Part_107_1921670.1359547007209
Content-Type: text/html; charset=ISO-8859-1

There are nine billion reasons not to define a macro. Why you wouldn't use a template function with a lambda, IDK, but not using a macro is kinda a given.

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_107_1921670.1359547007209--

.

On 30 January 2013 13:56, DeadMG <wolfeinstein@gmail.com> wrote:
> There are nine billion reasons not to define a macro. Why you wouldn't use a
> template function with a lambda, IDK, but not using a macro is kinda a
> given.

We're going off tangents here. For the original proposal, I fail to
see the benefit
of adding yet-another condition syntax, and putting that through the
specification
phases and waiting for it to be implemented reasonably-everywhere is a cost
I'd rather not suffer. Just because some other languages have an
unless is a rather
weak argument for adding it to c++, and the rationale is very unconvincing.

--

---
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/?hl=en.



.

Il 30/01/2013 12:58, Ville Voutilainen ha scritto:
> On 30 January 2013 13:56, DeadMG <wolfeinstein@gmail.com> wrote:
>> There are nine billion reasons not to define a macro. Why you wouldn't use a
>> template function with a lambda, IDK, but not using a macro is kinda a
>> given.
> We're going off tangents here. For the original proposal, I fail to
> see the benefit
> of adding yet-another condition syntax, and putting that through the
> specification
> phases and waiting for it to be implemented reasonably-everywhere is a cost
> I'd rather not suffer. Just because some other languages have an
> unless is a rather
> weak argument for adding it to c++, and the rationale is very unconvincing.
>
There actually is a use-case that is currently poorly addressed in C++.
Consider the following:

   if (auto x = f())
   { /*block */ }

the local variable x is constructed, then contextually converted to bool
and, if the result is *true* the block is executed. There's no simple
way to execute the block if the result of the conversion is false.
Adding extra parentheses won't help in this case. The obvious workaround is:

   if (auto x = f())
   {}
   else
   {  /*block */ }

which isn't very pretty. All other workarounds that come to my mind
require declaring x out the if-clause, so an extra couple of {} may be
needed, and possibly a static_cast<bool>, as comparing with "== false"
or rely on a double negation !! may not be feasible (the fact that a
type is contextually-convertible to bool doesn't mean it operator== or
operator! are available).

That said, I agree with Ville about the "limited-bandwidth" argument. We
have more important features waiting to be considered... Saving three
keystrokes (that's the difference between " not" vs. "{} else") doesn't
seem very urgent to me.

Ganesh

--

---
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/?hl=en.



.

On 30 January 2013 15:29, Alberto Barbati <albertobarbati@gmail.com> wrote:
> Il 30/01/2013 12:58, Ville Voutilainen ha scritto:
> There actually is a use-case that is currently poorly addressed in C++.
> Consider the following:
>   if (auto x = f())
>   { /*block */ }
> the local variable x is constructed, then contextually converted to bool
> and, if the result is *true* the block is executed. There's no simple way to
> execute the block if the result of the conversion is false. Adding extra
> parentheses won't help in this case. The obvious workaround is:
>   if (auto x = f())
>   {}
>   else
>   {  /*block */ }
> which isn't very pretty. All other workarounds that come to my mind require
> declaring x out the if-clause, so an extra couple of {} may be needed, and
> possibly a static_cast<bool>, as comparing with "== false" or rely on a
> double negation !! may not be feasible (the fact that a type is
> contextually-convertible to bool doesn't mean it operator== or operator! are
> available).

This would speak for adding an 'unless' to the language. I would find
that a much
better solution than allowing the 'not' in various places in an if.
The work-around
isn't pretty, that's for sure, but I wonder how severe this problem
is. I can write
wrappers that invert the boolean value if I want to avoid that empty statement
immediately followed by an else, but I don't know whether non-experts can.
The question is do those non-experts know that x is available in the
else? Do they try to do something like this, or do they just create a variable
outside the if-else scope?

--

---
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/?hl=en.



.

------=_Part_566_32955766.1359554965812
Content-Type: text/plain; charset=ISO-8859-1

On Wednesday, January 30, 2013 2:37:21 PM UTC+1, Ville Voutilainen wrote:

> On 30 January 2013 15:29, Alberto Barbati <alberto...@gmail.com<javascript:>>
> wrote:
> > Il 30/01/2013 12:58, Ville Voutilainen ha scritto:
> > There actually is a use-case that is currently poorly addressed in C++.
> > Consider the following:
> >   if (auto x = f())
> >   { /*block */ }
> > the local variable x is constructed, then contextually converted to bool
> > and, if the result is *true* the block is executed. There's no simple
> way to
> > execute the block if the result of the conversion is false. Adding extra
> > parentheses won't help in this case. The obvious workaround is:
> >   if (auto x = f())
> >   {}
> >   else
> >   {  /*block */ }
> > which isn't very pretty. All other workarounds that come to my mind
> require
> > declaring x out the if-clause, so an extra couple of {} may be needed,
> and
> > possibly a static_cast<bool>, as comparing with "== false" or rely on a
> > double negation !! may not be feasible (the fact that a type is
> > contextually-convertible to bool doesn't mean it operator== or operator!
> are
> > available).
>
> This would speak for adding an 'unless' to the language. I would find
> that a much
> better solution than allowing the 'not' in various places in an if.
> The work-around
> isn't pretty, that's for sure, but I wonder how severe this problem
> is. I can write
> wrappers that invert the boolean value if I want to avoid that empty
> statement
> immediately followed by an else, but I don't know whether non-experts can.
> The question is do those non-experts know that x is available in the
> else? Do they try to do something like this, or do they just create a
> variable
> outside the if-else scope?
>

I myself would much rather like to see a variable definition that can used
as an expression, rather than some exceptions in specific cases like it is
currently.

if ((auto f = foo()) && some_other_boolean)
    f->bar();

or

if ((SomeClass c(args)), c.SomeProperty())
    c.DoSomething();

Of course, care must be taken when using short-circuiting operators:

(auto a = foo()) && (auto b = bar()); // initialization of 'b' can't be
skipped just because 'a' evaluated to false.

--

---
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/?hl=en.



------=_Part_566_32955766.1359554965812
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 30, 2013 2:37:21 PM UTC+1, Ville Voutilainen wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">On 30 January 2013 15:29, Al=
berto Barbati &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"0BFkkMb-cFUJ">alberto...@gmail.com</a>&gt; wrote:
<br>&gt; Il 30/01/2013 12:58, Ville Voutilainen ha scritto:
<br>&gt; There actually is a use-case that is currently poorly addressed in=
 C++.
<br>&gt; Consider the following:
<br>&gt; &nbsp; if (auto x =3D f())
<br>&gt; &nbsp; { /*block */ }
<br>&gt; the local variable x is constructed, then contextually converted t=
o bool
<br>&gt; and, if the result is *true* the block is executed. There's no sim=
ple way to
<br>&gt; execute the block if the result of the conversion is false. Adding=
 extra
<br>&gt; parentheses won't help in this case. The obvious workaround is:
<br>&gt; &nbsp; if (auto x =3D f())
<br>&gt; &nbsp; {}
<br>&gt; &nbsp; else
<br>&gt; &nbsp; { &nbsp;/*block */ }
<br>&gt; which isn't very pretty. All other workarounds that come to my min=
d require
<br>&gt; declaring x out the if-clause, so an extra couple of {} may be nee=
ded, and
<br>&gt; possibly a static_cast&lt;bool&gt;, as comparing with "=3D=3D fals=
e" or rely on a
<br>&gt; double negation !! may not be feasible (the fact that a type is
<br>&gt; contextually-convertible to bool doesn't mean it operator=3D=3D or=
 operator! are
<br>&gt; available).
<br>
<br>This would speak for adding an 'unless' to the language. I would find
<br>that a much
<br>better solution than allowing the 'not' in various places in an if.
<br>The work-around
<br>isn't pretty, that's for sure, but I wonder how severe this problem
<br>is. I can write
<br>wrappers that invert the boolean value if I want to avoid that empty st=
atement
<br>immediately followed by an else, but I don't know whether non-experts c=
an.
<br>The question is do those non-experts know that x is available in the
<br>else? Do they try to do something like this, or do they just create a v=
ariable
<br>outside the if-else scope?
<br></blockquote><div><br></div><div>I myself would much rather like to see=
 a variable definition that can used as an expression, rather than some exc=
eptions in specific cases like it is currently.</div><div><br></div><div>if=
 ((auto f =3D foo()) &amp;&amp; some_other_boolean)</div><div>&nbsp; &nbsp;=
 f-&gt;bar();</div><div><br></div><div>or</div><div><br></div><div>if ((Som=
eClass c(args)), c.SomeProperty())</div><div>&nbsp; &nbsp; c.DoSomething();=
</div><div><br></div><div>Of course, care must be taken when using short-ci=
rcuiting operators:</div><div><br></div><div>(auto a =3D foo()) &amp;&amp; =
(auto b =3D bar()); // initialization of 'b' can't be skipped just because =
'a' evaluated to false.</div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_566_32955766.1359554965812--

.

On 30 January 2013 16:09, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
>> This would speak for adding an 'unless' to the language. I would find
> I myself would much rather like to see a variable definition that can used
> as an expression, rather than some exceptions in specific cases like it is
> currently.
> if ((auto f = foo()) && some_other_boolean)
>     f->bar();

Ah. Interesting. Now we're entering deep and muddy waters. :) The question
for something like that is whether the work-arounds are more reasonable
than adding that complexity into the language. Having said that, having
a variable definition be an expression would be much much more generic
than just fiddling with the position of a 'not' or something similar.
Especially when
we consider the possibility of having multiple variables potentially
short-circuited
as you showed. At this point I'm strongly skeptic and mildly opposed to
adding such a facility. That, of course, doesn't mean that such a proposal
couldn't be submitted. ;)

--

---
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/?hl=en.



.

------=_Part_59_21127443.1359579510136
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

*If an expression like (index  < end) needs to be negated and one does not=
=20
want to transform the expression=92s logic in favor of recognition and=20
readability one has to put parentheses ( ! (index < end) ). It depends on=
=20
the programming style but from my point of view it=92s quite a common case.
Sure, this extension would not be a significant novelty but on the other=20
hand it would be quite handy and the implementation effort is probably=20
moderate.=20

It is also a question of symmetry. If an expression can be checked for=20
trueness why shouldn=92t it be possible to check for falseness?*

--=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/?hl=3Den.



------=_Part_59_21127443.1359579510136
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<b id=3D"internal-source-marker_0.12558542913757265" style=3D"color: rgb(0,=
 0, 0); font-family: 'Times New Roman'; font-size: medium; "><span style=3D=
"font-size: 15px; font-family: Arial; background-color: transparent; font-w=
eight: normal; white-space: pre-wrap; ">If an expression like (index &nbsp;=
&lt; end) needs to be negated and one does not want to transform the expres=
sion=92s logic in favor of recognition and readability one has to put paren=
theses ( ! (index &lt; end) ). It depends on the programming style but from=
 my point of view it=92s quite a common case.</span><br><span style=3D"font=
-size: 15px; font-family: Arial; background-color: transparent; font-weight=
: normal; white-space: pre-wrap; ">Sure, this extension would not be a sign=
ificant novelty but on the other hand it would be quite handy and the imple=
mentation effort is probably moderate. </span><br><span style=3D"font-size:=
 15px; font-family: Arial; background-color: transparent; font-weight: norm=
al; white-space: pre-wrap; "></span><br><span style=3D"font-size: 15px; fon=
t-family: Arial; background-color: transparent; font-weight: normal; white-=
space: pre-wrap; ">It is also a question of symmetry. If an expression can =
be checked for trueness why shouldn=92t it be possible to check for falsene=
ss?</span></b><br>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_59_21127443.1359579510136--

.

On 30 January 2013 22:58, Hanspeter Bieri-Ineichen <bieri.hp@gmail.com> wro=
te:
> If an expression like (index  < end) needs to be negated and one does not
> want to transform the expression=92s logic in favor of recognition and
> readability one has to put parentheses ( ! (index < end) ). It depends on
> the programming style but from my point of view it=92s quite a common cas=
e.
> Sure, this extension would not be a significant novelty but on the other
> hand it would be quite handy and the implementation effort is probably
> moderate.

I find it odd it !(a < b) is more familiar and readable than a>=3Db. This s=
eems
like it's a feature request based on a certain familiarity background. That=
 in
and of itself is not a very strong rationale. It sounds like a
"wouldn't it be nice if..".
And the answer can be "sure", "hell no", or "maybe", depending on who you
ask.

> It is also a question of symmetry. If an expression can be checked for
> trueness why shouldn=92t it be possible to check for falseness?

Well, it's already possible. Whether the syntax for that is optimized
is a completely
different matter.

--=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/?hl=3Den.



.

------=_Part_1464_23298808.1360191425769
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Often expressions like (index < end) are negated as (index >=E2=81=BC end) =
instead=20
of ( ! ( index < end ) ) because it is less writing. With the proposal one=
=20
can quickly write ! ( index < end) .

This improves readability because the original expression (index < end) is=
=20
not modified.

--=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/?hl=3Den.



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

Often expressions like (index &lt; end) are negated as (index &gt;=E2=81=BC=
 end) instead of ( ! ( index &lt; end ) ) because it is less writing. With =
the proposal one can quickly write ! ( index &lt; end) .<br><br>This improv=
es readability because the original expression (index &lt; end) is not modi=
fied.

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1464_23298808.1360191425769--

.

------=_Part_663_33333347.1360192413267
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Wednesday, February 6, 2013 2:57:05 PM UTC-8, Hanspeter Bieri-Ineichen=
=20
wrote:
>
> Often expressions like (index < end) are negated as (index >=E2=81=BC end=
) instead=20
> of ( ! ( index < end ) ) because it is less writing. With the proposal on=
e=20
> can quickly write ! ( index < end) .
>
> This improves readability because the original expression (index < end) i=
s=20
> not modified.


How does this improve readability? You're doing greater than or equals=20
(unless you're testing floats and NaNs are a possibility). It's more=20
readable to see that the test is >=3D, not !(<), which requires a bit more=
=20
effort to understand.

--=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/?hl=3Den.



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

<br><br>On Wednesday, February 6, 2013 2:57:05 PM UTC-8, Hanspeter Bieri-In=
eichen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Often expressions=
 like (index &lt; end) are negated as (index &gt;=E2=81=BC end) instead of =
( ! ( index &lt; end ) ) because it is less writing. With the proposal one =
can quickly write ! ( index &lt; end) .<br><br>This improves readability be=
cause the original expression (index &lt; end) is not modified.</blockquote=
><div><br>How does this improve readability? You're doing greater than or e=
quals (unless you're testing floats and NaNs are a possibility). It's more =
readable to see that the test is &gt;=3D, not !(&lt;), which requires a bit=
 more effort to understand.<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_663_33333347.1360192413267--

.

------=_Part_262_32079894.1360402827864
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, January 30, 2013 3:16:13 PM UTC+4, Sylvester Hesp wrote:
>
> On Wednesday, January 30, 2013 10:06:47 AM UTC+1, Andrzej Krzemie=C5=84sk=
i=20
> wrote:
>>
>> Why don't you define a macro:
>>
>> #define UNLESS(cond) if(cond){}else
>>
>> It gives a quite reasonable behavior:
>>
>> UNLESS (auto p =3D get_ptr()) ...
>>
>>
> That won't work if you also want to use 'else'.
>

If we would want to use 'else' with 'unless', we could use

    if (cond) s2 else s1

instead of

    unless (cond) s1 else s2

--=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/?hl=3Den.



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

On Wednesday, January 30, 2013 3:16:13 PM UTC+4, Sylvester Hesp wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On Wednesday, January 30, 2013 10:0=
6:47 AM UTC+1, Andrzej Krzemie=C5=84ski wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">Why don't you define a macro:<br><br><div style=3D"background-co=
lor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;borde=
r-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#800">#de=
fine</span><span style=3D"color:#000"> UNLESS</span><span style=3D"color:#6=
60">(</span><span style=3D"color:#000">cond</span><span style=3D"color:#660=
">)</span><span style=3D"color:#000"> </span><span style=3D"color:#008">if<=
/span><span style=3D"color:#660">(</span><span style=3D"color:#000">cond</s=
pan><span style=3D"color:#660">){}</span><span style=3D"color:#008">else</s=
pan><span style=3D"color:#000"><br></span></div></code></div><br>It gives a=
 quite reasonable behavior:<br><br><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code><div><span style=3D"color:#000">UNLESS </span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#008">auto</span><spa=
n style=3D"color:#000"> p </span><span style=3D"color:#660">=3D</span><span=
 style=3D"color:#000"> get_ptr</span><span style=3D"color:#660">())</span><=
span style=3D"color:#000"> </span><span style=3D"color:#660">...</span><spa=
n style=3D"color:#000"><br></span></div></code></div><br></blockquote><div>=
<br></div><div>That won't work if you also want to use 'else'.</div></block=
quote><div><br>If we would want to use 'else' with 'unless', we could use<b=
r><br>&nbsp;&nbsp;&nbsp; if (cond) s2 else s1<br><br>instead of<br><br>&nbs=
p;&nbsp;&nbsp; unless (cond) s1 else s2<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_262_32079894.1360402827864--

.

Le 30/01/2013 14:29, Alberto Barbati a =C3=A9crit :
> comparing with "=3D=3D false" or rely on a double negation !! may not be=
=20
> feasible (the fact that a type is contextually-convertible to bool=20
> doesn't mean it operator=3D=3D or operator! are available).
>

Do you know real world types conditionally convertible to bool and not=20
providing operator! ?


--=20
Lo=C4=8Fc

--=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/?hl=3Den.



.

2013/2/10 Lo=EFc Joly <loic.actarus.joly@numericable.fr>:
> Le 30/01/2013 14:29, Alberto Barbati a =E9crit :
>
>> comparing with "=3D=3D false" or rely on a double negation !! may not be
>> feasible (the fact that a type is contextually-convertible to bool doesn=
't
>> mean it operator=3D=3D or operator! are available).
>>
>
> Do you know real world types conditionally convertible to bool and not
> providing operator! ?

(I assume you mean "contextually convertible to bool) The standard
smart pointers,
for example. I have not fully read the whole thread, but I don't see
any need for
operator! once you have a contextual conversion to bool, because
logical negation operator
also defines a contextual conversion to bool ([expr.unary.op] p9).

- Daniel

--=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/?hl=3Den.



.