------=_Part_959_2134635472.1425407953043
Content-Type: multipart/alternative;
 boundary="----=_Part_960_956571122.1425407953043"

------=_Part_960_956571122.1425407953043
Content-Type: text/plain; charset=UTF-8

For a function taking Boolean parameters:

function(bool enableLogging, bool enableWarnings);

wouldn't it be useful to be able to call it thus:

function(enableLogging, enableWarnings);

(i.e. without explicitly defining enableLogging and enableWarnings prior to
the call) and having it be equivalent to:

const bool enableLogging = true;
const bool enableWarnings = true;
function(enableLogging, enableWarnings);

This would allow us to:
1) Eliminate irritating code like: function(true, true, false, true, false,
false);
2) Save code space for not having to define Boolean variables.

Leo

--

---
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_960_956571122.1425407953043
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>For a function taking Boolean parameters:</div><div><=
font face=3D"courier new, monospace"><br></font></div><div><font face=3D"co=
urier new, monospace">function(bool enableLogging, bool enableWarnings);</f=
ont></div><div><br></div><div>wouldn't it be useful to be able to call it t=
hus:<br></div><div><br></div><div><font face=3D"courier new, monospace">fun=
ction(enableLogging, enableWarnings);</font></div><div><br></div><div>(i.e.=
 without explicitly defining <font face=3D"courier new, monospace">enableLo=
gging </font>and <font face=3D"courier new, monospace">enableWarnings </fon=
t>prior to the call) and having it be equivalent to:</div><div><br></div><d=
iv><font face=3D"courier new, monospace">const bool enableLogging =3D true;=
</font></div><div><font face=3D"courier new, monospace">const bool enableWa=
rnings =3D true;</font></div><div><font face=3D"courier new, monospace">fun=
ction(enableLogging, enableWarnings);</font></div><div><br></div><div>This =
would allow us to:</div><div>1) Eliminate irritating code like: <font face=
=3D"courier new, monospace">function(true, true, false, true, false, false)=
;</font></div><div>2) Save code space for not having to define Boolean vari=
ables.</div><div><br></div><div>Leo</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_960_956571122.1425407953043--
------=_Part_959_2134635472.1425407953043--

.

You could always use enums?

On 3/3/15, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> For a function taking Boolean parameters:
>
> function(bool enableLogging, bool enableWarnings);
>
> wouldn't it be useful to be able to call it thus:
>
> function(enableLogging, enableWarnings);
>
> (i.e. without explicitly defining enableLogging and enableWarnings prior to
>
> the call) and having it be equivalent to:
>
> const bool enableLogging = true;
> const bool enableWarnings = true;
> function(enableLogging, enableWarnings);
>
> This would allow us to:
> 1) Eliminate irritating code like: function(true, true, false, true, false,
>
> false);
> 2) Save code space for not having to define Boolean variables.
>
> Leo
>
> --
>
> ---
> 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/.

.

--001a113f96c23e9191051066cdb3
Content-Type: text/plain; charset=UTF-8

Implicit declaration of types is a rather treacherous bug source. Imagine
if someone had a typo on their code and ended up passing a bool instead of
the object they expected.

Besides, why true for default?

2015-03-03 15:39 GMT-03:00 Leo Heinsaar <leoheinsaar@gmail.com>:

> For a function taking Boolean parameters:
>
> function(bool enableLogging, bool enableWarnings);
>
> wouldn't it be useful to be able to call it thus:
>
> function(enableLogging, enableWarnings);
>
> (i.e. without explicitly defining enableLogging and enableWarnings prior
> to the call) and having it be equivalent to:
>
> const bool enableLogging = true;
> const bool enableWarnings = true;
> function(enableLogging, enableWarnings);
>
> This would allow us to:
> 1) Eliminate irritating code like: function(true, true, false, true,
> false, false);
> 2) Save code space for not having to define Boolean variables.
>
> Leo
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Implicit declaration of types is a rather treacherous bug =
source. Imagine if someone had a typo on their code and ended up passing a =
bool instead of the object they expected.<div><br></div><div>Besides, why t=
rue for default?</div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">2015-03-03 15:39 GMT-03:00 Leo Heinsaar <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:leoheinsaar@gmail.com" target=3D"_blank">leoheinsaar@gmail.=
com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>For a function taking Boolean parameters:</div><div><font face=3D"courier =
new, monospace"><br></font></div><div><font face=3D"courier new, monospace"=
>function(bool enableLogging, bool enableWarnings);</font></div><div><br></=
div><div>wouldn&#39;t it be useful to be able to call it thus:<br></div><di=
v><br></div><div><font face=3D"courier new, monospace">function(enableLoggi=
ng, enableWarnings);</font></div><div><br></div><div>(i.e. without explicit=
ly defining <font face=3D"courier new, monospace">enableLogging </font>and =
<font face=3D"courier new, monospace">enableWarnings </font>prior to the ca=
ll) and having it be equivalent to:</div><div><br></div><div><font face=3D"=
courier new, monospace">const bool enableLogging =3D true;</font></div><div=
><font face=3D"courier new, monospace">const bool enableWarnings =3D true;<=
/font></div><div><font face=3D"courier new, monospace">function(enableLoggi=
ng, enableWarnings);</font></div><div><br></div><div>This would allow us to=
:</div><div>1) Eliminate irritating code like: <font face=3D"courier new, m=
onospace">function(true, true, false, true, false, false);</font></div><div=
>2) Save code space for not having to define Boolean variables.</div><span =
class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div>Leo</div></fon=
t></span></div><span class=3D"HOEnZb"><font color=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><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 />

--001a113f96c23e9191051066cdb3--

.

------=_Part_16_1858582501.1425409392305
Content-Type: multipart/alternative;
 boundary="----=_Part_17_2046448692.1425409392305"

------=_Part_17_2046448692.1425409392305
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wrote:
>
> You could always use enums?


Enums you would still have to define somewhere else; might as well define
the Boolean variables...

--

---
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_17_2046448692.1425409392305
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Do=
uglas Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You could a=
lways use enums? </blockquote><div><br></div><div>Enums you would still hav=
e to define somewhere else; might as well define the Boolean variables...</=
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_17_2046448692.1425409392305--
------=_Part_16_1858582501.1425409392305--

.

Correct me if I'm wrong, but I understood the OP, the problem was with
using bools.

On 3/3/15, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
>
>
> On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wrote:
>>
>> You could always use enums?
>
>
> Enums you would still have to define somewhere else; might as well define
> the Boolean variables...
>
> --
>
> ---
> 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_5402_447171634.1425410482316
Content-Type: multipart/alternative;
 boundary="----=_Part_5403_1568371785.1425410482316"

------=_Part_5403_1568371785.1425410482316
Content-Type: text/plain; charset=UTF-8

On Tuesday, March 3, 2015 at 10:50:01 PM UTC+4, Pablo Oliva wrote:
>
> Implicit declaration of types is a rather treacherous bug source. Imagine
> if someone had a typo on their code and ended up passing a bool instead of
> the object they expected.
>

Not sure what you mean.


> Besides, why true for default?
>

There really isn't much difference, so true sort of seems positive.

For falses, we'd, obviously, write function(!enableLogging,
!enableWarnings);


--

---
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_5403_1568371785.1425410482316
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, March 3, 2015 at 10:50:01 PM UTC+4, Pablo Oliv=
a 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">Impli=
cit declaration of types is a rather treacherous bug source. Imagine if som=
eone had a typo on their code and ended up passing a bool instead of the ob=
ject they expected.</div></blockquote><div><br></div><div>Not sure what you=
 mean.</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;"><=
div dir=3D"ltr"><div></div><div>Besides, why true for default?</div></div><=
/blockquote><div><br></div><div>There really isn't much difference, so true=
 sort of seems positive.</div><div><br></div><div>For <font face=3D"courier=
 new, monospace">false</font>s, we'd, obviously, write <font face=3D"courie=
r new, monospace">function(!enableLogging, !enableWarnings);</font></div><d=
iv>&nbsp;</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_5403_1568371785.1425410482316--
------=_Part_5402_447171634.1425410482316--

.

------=_Part_5197_1290352030.1425410563988
Content-Type: multipart/alternative;
 boundary="----=_Part_5198_1656700804.1425410563988"

------=_Part_5198_1656700804.1425410563988
Content-Type: text/plain; charset=UTF-8

That's right; I'm not sure where the misunderstanding is then...

On Tuesday, March 3, 2015 at 11:08:06 PM UTC+4, Douglas Boffey wrote:
>
> Correct me if I'm wrong, but I understood the OP, the problem was with
> using bools.
>
> On 3/3/15, Leo Heinsaar <leohe...@gmail.com <javascript:>> wrote:
> >
> >
> > On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wrote:
> >>
> >> You could always use enums?
> >
> >
> > Enums you would still have to define somewhere else; might as well
> define
> > the Boolean variables...
> >
> > --
> >
> > ---
> > 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-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > 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_5198_1656700804.1425410563988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That's right; I'm not sure where the misunderstanding=
 is then...</div><br>On Tuesday, March 3, 2015 at 11:08:06 PM UTC+4, Dougla=
s Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Correct me if I=
'm wrong, but I understood the OP, the problem was with
<br>using bools.
<br>
<br>On 3/3/15, Leo Heinsaar &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"oAAKVjvY8TUJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">leohe...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wro=
te:
<br>&gt;&gt;
<br>&gt;&gt; You could always use enums?
<br>&gt;
<br>&gt;
<br>&gt; Enums you would still have to define somewhere else; might as well=
 define
<br>&gt; the Boolean variables...
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; "ISO C++ Standard - Future Proposals" group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br>&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"oAAKVjvY8TUJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">std=
-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"oAAKVjvY8TUJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://=
groups.google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=
=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/=
';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>p=
roposals/</a>.
<br>&gt;
<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_5198_1656700804.1425410563988--
------=_Part_5197_1290352030.1425410563988--

.

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

If I understand it correctly you are asking for the compiler to pick the
name from the declaration of the function and allow it as a boolean 'true'
at the call site.

void f(bool x);
f(x); // translated to f(true)

So here are some of the concerns: there could be multiple declarations of
the function with different names (either intentionally or by mistake),
which should be allowed, the first? any?

void f(bool x);
void f(bool isX);
f(x) ? f(isX) ? both?

It might even be the case that the declarations in sight don't even provide
names for the arguments...

Changing this in the standard has the potential to break existing programs:

void f(bool x);
void g() {
    const bool x = false;
    f(x);  // f(true)? f(false)?
}

Not only regarding the value, but depending at what stage the substitution
is used, the 'x' might shadow an existing variable:

namespace N { struct T {}; void f(T); }
N::T x;
void g() {
   f(x);        // f(true)? ::N::f(::x) ?
}

Under what circumstances would the substitution take place?

bool h(bool a);
void f(bool x);
f(h(x)); // f(h(true)) ? or is this limited to direct use?
f((x)); // ?
f(condition ? x : !x); // what about this?

I don't see much value in the feature, and I don't know whether the
language would be better or worse with that feature... Of course, going one
step further the real feature would have having named parameters:

f(x := true); // whatever syntax for this would be

    David

On Tue, Mar 3, 2015 at 2:22 PM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:

> That's right; I'm not sure where the misunderstanding is then...
>
> On Tuesday, March 3, 2015 at 11:08:06 PM UTC+4, Douglas Boffey wrote:
>>
>> Correct me if I'm wrong, but I understood the OP, the problem was with
>> using bools.
>>
>> On 3/3/15, Leo Heinsaar <leohe...@gmail.com> wrote:
>> >
>> >
>> > On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wrote:
>> >>
>> >> You could always use enums?
>> >
>> >
>> > Enums you would still have to define somewhere else; might as well
>> define
>> > the Boolean variables...
>> >
>> > --
>> >
>> > ---
>> > 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-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@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/.
>

--

---
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/.

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

<div dir=3D"ltr">If I understand it correctly you are asking for the compil=
er to pick the name from the declaration of the function and allow it as a =
boolean &#39;true&#39; at the call site.<br><br>void f(bool x);<br>f(x); //=
 translated to f(true)<br><br>So here are some of the concerns: there could=
 be multiple declarations of the function with different names (either inte=
ntionally or by mistake), which should be allowed, the first? any?<br><br>v=
oid f(bool x);<br>void f(bool isX);<br>f(x) ? f(isX) ? both?<br><br>It migh=
t even be the case that the declarations in sight don&#39;t even provide na=
mes for the arguments...<br><br>Changing this in the standard has the poten=
tial to break existing programs:<br><br>void f(bool x);<br>void g() {<br>=
=C2=A0 =C2=A0 const bool x =3D false;<br>=C2=A0 =C2=A0 f(x); =C2=A0// f(tru=
e)? f(false)?<br>}<br><br>Not only regarding the value, but depending at wh=
at stage the substitution is used, the &#39;x&#39; might shadow an existing=
 variable:<br><br>namespace N { struct T {}; void f(T); }<br>N::T x;<br>voi=
d g() {<br>=C2=A0 =C2=A0f(x); =C2=A0 =C2=A0 =C2=A0 =C2=A0// f(true)? ::N::f=
(::x) ?<br>}<br><br>Under what circumstances would the substitution take pl=
ace?<br><br>bool h(bool a);<br>void f(bool x);<br>f(h(x)); // f(h(true)) ? =
or is this limited to direct use?<br>f((x)); // ?<br>f(condition ? x : !x);=
 // what about this?<br><br>I don&#39;t see much value in the feature, and =
I don&#39;t know whether the language would be better or worse with that fe=
ature... Of course, going one step further the real feature would have havi=
ng named parameters:<br><br>f(x :=3D true); // whatever syntax for this wou=
ld be<br><br>=C2=A0 =C2=A0 David</div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Tue, Mar 3, 2015 at 2:22 PM, Leo Heinsaar <span dir=
=3D"ltr">&lt;<a href=3D"mailto:leoheinsaar@gmail.com" target=3D"_blank">leo=
heinsaar@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><div>That&#39;s right; I&#39;m not sure where the misunder=
standing is then...</div><span class=3D""><br>On Tuesday, March 3, 2015 at =
11:08:06 PM UTC+4, Douglas Boffey wrote:</span><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><span class=3D"">Correct me if I&#39;m wrong, but I understood =
the OP, the problem was with
<br>using bools.
<br>
<br></span><span class=3D"">On 3/3/15, Leo Heinsaar &lt;<a rel=3D"nofollow"=
>leohe...@gmail.com</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wro=
te:
<br>&gt;&gt;
<br>&gt;&gt; You could always use enums?
<br>&gt;
<br>&gt;
<br>&gt; Enums you would still have to define somewhere else; might as well=
 define
<br>&gt; the Boolean variables...
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br></span>&gt; email to <a rel=3D"nofollow">std-proposal...@<u></u>isocpp.=
org</a>.
<br>&gt; To post to this group, send email to <a rel=3D"nofollow">std-pr...=
@isocpp.org</a>.
<br><span class=3D"">&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com/a/<u></u>i=
socpp.org/group/std-<u></u>proposals/</a>.
<br>&gt;
<br></span></blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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 />

--f46d043be09e01f80d051067eda9--

.

------=_Part_872_225958485.1425413730643
Content-Type: multipart/alternative;
 boundary="----=_Part_873_933169499.1425413730643"

------=_Part_873_933169499.1425413730643
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 3, 2015 at 2:03:12 PM UTC-5, Leo Heinsaar wrote:
>
>
>
> On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wrote:
>>
>> You could always use enums?
>
>
> Enums you would still have to define somewhere else; might as well define
> the Boolean variables...
>

Not sure what you mean, here. So if we have...

*void f(bool op1, bool op2, bool op3);*

We can change this to using enums using powers of 2...

*enum Flags { ENABLE_LOGGING = 1, ENABLE_WARNING = 2, OTHER = 4, ... };*
*void f(int flags);*

And we can call it without defining any boolean variables.

*f(ENABLE_LOGGING | ENABLE_WARNING | etc...);*

and you get almost the exact syntax being proposed, just replacing commas
(,)
with bars (|). You also reduce the number of arguments to f to one (optimal)
and the same flags may be used for other functions, too (generic).  Why
should
we prefer adding a language feature that could introduce ambiguous
statements
to this decades-old technique?


The only update I can think of is maybe *std::bitset* could be used and the
*"enable_logging"* etc. flags could be *constexpr *global *bitset*s, too.
Never tried it.

--

---
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_873_933169499.1425413730643
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, March 3, 2015 at 2:03:12 PM UTC-5, Leo=
 Heinsaar 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"lt=
r"><br><br>On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex">You could always use enums? </=
blockquote><div><br></div><div>Enums you would still have to define somewhe=
re else; might as well define the Boolean variables...</div></div></blockqu=
ote><div><br></div><div>Not sure what you mean, here. So if we have...</div=
><div><br></div><div><i>void f(bool op1, bool op2, bool op3);</i></div><div=
><br></div><div>We can change this to using enums using powers of 2...</div=
><div><br></div><div><i>enum Flags { ENABLE_LOGGING =3D 1, ENABLE_WARNING =
=3D 2, OTHER =3D 4, ... };</i></div><div><i>void f(int flags);</i></div><di=
v><i><br></i></div><div>And we can call it without defining any boolean var=
iables.</div><div><i><br></i></div><div><i>f(ENABLE_LOGGING | ENABLE_WARNIN=
G | etc...);</i></div><div><i><br></i></div><div><div>and you get almost th=
e exact syntax being proposed, just replacing commas (,)</div><div>with bar=
s (|). You also reduce the number of arguments to f to one (optimal)</div><=
div>and the same flags may be used for other functions, too (generic). &nbs=
p;Why should</div><div>we prefer adding a language feature that could intro=
duce ambiguous statements</div><div>to this decades-old technique?</div></d=
iv><div><br></div><div><br></div><div>The only update I can think of is may=
be <i>std::bitset</i>&nbsp;could be used and the&nbsp;</div><div><i>"enable=
_logging"</i>&nbsp;etc. flags could be&nbsp;<i>constexpr </i>global <i>bits=
et</i>s, too. Never tried it.</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_873_933169499.1425413730643--
------=_Part_872_225958485.1425413730643--

.

On Tuesday 03 March 2015 12:15:30 Scott Prager wrote:
> *f(ENABLE_LOGGING | ENABLE_WARNING | etc...);*
>
> and you get almost the exact syntax being proposed, just replacing commas
> (,)
> with bars (|). You also reduce the number of arguments to f to one (optimal)
> and the same flags may be used for other functions, too (generic).  Why
> should
> we prefer adding a language feature that could introduce ambiguous
> statements
> to this decades-old technique?

Adding more drawbacks to the proposal:

1) the names of the arguments become part of the API. You can't fix
misspellings that may be missed through code reviews and you can't work around
bad #defines (#define interface in MS headers, for example).

2) you can't easily get the setting from an external variable or function. How
would you do:

 f(globalSettings | ENABLE_WARNING);

Assuming that one boolean variable per setting is fine (globalEnableXxxx),
you'd have to write:

 f(globalEnableLogging, enableWarning, globalEnableError, globalEnableFatals);

3) you can't reorder the arguments

Instead, I recommend merging this proposal to the one about passing named
parameters to functions and object constructors. This was discussed for some
time but never made to a proposal. That is still affected by problem #1 above,
but it was more generic.

--
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_1427_240218457.1425433882211
Content-Type: multipart/alternative;
 boundary="----=_Part_1428_82350439.1425433882211"

------=_Part_1428_82350439.1425433882211
Content-Type: text/plain; charset=UTF-8

On Tuesday, March 3, 2015 at 2:21:22 PM UTC-5, Leo Heinsaar wrote:
>
> On Tuesday, March 3, 2015 at 10:50:01 PM UTC+4, Pablo Oliva wrote:
>>
>> Implicit declaration of types is a rather treacherous bug source. Imagine
>> if someone had a typo on their code and ended up passing a bool instead of
>> the object they expected.
>>
>
> Not sure what you mean.
>
>
>> Besides, why true for default?
>>
>
> There really isn't much difference, so true sort of seems positive.
>
> For falses, we'd, obviously, write function(!enableLogging,
> !enableWarnings);
>
>

OK, so how exactly does that makes sense? To either the reader of the code
or the compiler?

What is the compilation algorithm here, exactly? Does the compiler look at
the function parameter names, and then decide that if it encounters an
undeclared identifier that matches the same parameter name as the argument
it's currently in, it will pretend that this identifier is a bool who's
value is true?

So, is this legal?

bool *foo = nullptr;
function(foo = &enableLogging, enableWarnings);

If so... what's the lifetime of these magical identifiers? After the
function call, is 'foo' pointing to real memory?

You are suggesting that the compiler should create magical identifiers that
magically fill themselves with values, without having ever been defined.
But only in function argument lists. And only where that identifier name
matches the corresponding parameter. And only when the type is a bool.

Isn't that way to special-case to bother standardizing? I understand the
readability improvements, for these certain cases. But the language just
doesn't work that way.

Personally, I'm against any feature that uses the names that the function
argument lists uses mean anything to any code that isn't the function's
definition.

--

---
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_1428_82350439.1425433882211
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, March 3, 2015 at 2:21:22 PM UTC-5, Leo Heinsaa=
r 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 Tu=
esday, March 3, 2015 at 10:50:01 PM UTC+4, Pablo Oliva wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">Implicit declaration of types is=
 a rather treacherous bug source. Imagine if someone had a typo on their co=
de and ended up passing a bool instead of the object they expected.</div></=
blockquote><div><br></div><div>Not sure what you mean.</div><div>&nbsp;</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>=
Besides, why true for default?</div></div></blockquote><div><br></div><div>=
There really isn't much difference, so true sort of seems positive.</div><d=
iv><br></div><div>For <font face=3D"courier new, monospace">false</font>s, =
we'd, obviously, write <font face=3D"courier new, monospace">function(!enab=
leLogging, !enableWarnings);</font></div><div>&nbsp;</div></div></blockquot=
e><div><br>OK, so how exactly does that makes sense? To either the reader o=
f the code or the compiler?<br><br>What is the compilation algorithm here, =
exactly? Does the compiler look at the function parameter names, and then d=
ecide that if it encounters an undeclared identifier that matches the same =
parameter name as the argument it's currently in, it will pretend that this=
 identifier is a bool who's value is true?<br><br>So, is this legal?<br><br=
>bool *foo =3D nullptr;<br>function(foo =3D &amp;enableLogging, enableWarni=
ngs);<br><br>If so... what's the lifetime of these magical identifiers? Aft=
er the function call, is 'foo' pointing to real memory?<br><br>You are sugg=
esting that the compiler should create magical identifiers=20
that magically fill themselves with values, without having ever been=20
defined. But only in function argument lists. And only where that=20
identifier name matches the corresponding parameter. And only when the type=
 is a bool.<br><br>Isn't that way to special-case to bother standardizing? =
I understand the readability improvements, for these certain cases. But the=
 language just doesn't work that way.<br><br>Personally, I'm against any fe=
ature that uses the names that the function argument lists uses mean anythi=
ng to any code that isn't the function's definition.<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_1428_82350439.1425433882211--
------=_Part_1427_240218457.1425433882211--

.

------=_Part_3566_614068910.1425446680123
Content-Type: multipart/alternative;
 boundary="----=_Part_3567_1997246535.1425446680123"

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


On Wednesday, March 4, 2015 at 12:10:30 AM UTC+4, David Rodr=C3=ADguez Ibea=
s=20
wrote:
>
> If I understand it correctly you are asking for the compiler to pick the=
=20
> name from the declaration of the function and allow it as a boolean 'true=
'=20
> at the call site.
>

No, definitely not by picking up the name - just the type. This has been=20
brought up in many other replies below - sorry folks for being unclear:=20
names should be irrelevant. Simply my example was what one would write in=
=20
real code.

--=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/.

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

<div dir=3D"ltr"><br>On Wednesday, March 4, 2015 at 12:10:30 AM UTC+4, Davi=
d Rodr=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">If I understand it correctly you are asking for the compile=
r to pick the name from the declaration of the function and allow it as a b=
oolean 'true' at the call site.<br></div></blockquote><div><br></div><div>N=
o, definitely not by picking up the name - just the type. This has been bro=
ught up in many other replies below - sorry folks for being unclear: names =
should be irrelevant. Simply my example was what one would write in real co=
de.</div><div><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_3567_1997246535.1425446680123--
------=_Part_3566_614068910.1425446680123--

.

------=_Part_5725_1446900003.1425447024043
Content-Type: multipart/alternative;
 boundary="----=_Part_5726_2091015440.1425447024043"

------=_Part_5726_2091015440.1425447024043
Content-Type: text/plain; charset=UTF-8


>
> On Tuesday, March 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wrote:
>>>
>>> You could always use enums?
>>
>>
>> Enums you would still have to define somewhere else; might as well define
>> the Boolean variables...
>>
>
> Not sure what you mean, here. So if we have...
>
> *void f(bool op1, bool op2, bool op3);*
>
> We can change this to using enums using powers of 2...
>
> *enum Flags { ENABLE_LOGGING = 1, ENABLE_WARNING = 2, OTHER = 4, ... };*
> *void f(int flags);*
>
> And we can call it without defining any boolean variables.
>
> *f(ENABLE_LOGGING | ENABLE_WARNING | etc...);*
>

Well, if we're going to do define the enum values, we might as well define
the bools (as true, and then use their negation where the negative is
needed) - that's what I meant.

Also, I'm mostly concerned about *existing* functions which already take
bools as arguments. Certainly when you're designing an API, you could
choose to have an int as a parameter and do the flags.

--

---
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_5726_2091015440.1425447024043
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, Ma=
rch 3, 2015 at 10:49:09 PM UTC+4, Douglas Boffey wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">You could always use enums? </blockquote><div><br></div=
><div>Enums you would still have to define somewhere else; might as well de=
fine the Boolean variables...</div></div></blockquote><div><br></div><div>N=
ot sure what you mean, here. So if we have...</div><div><br></div><div><i>v=
oid f(bool op1, bool op2, bool op3);</i></div><div><br></div><div>We can ch=
ange this to using enums using powers of 2...</div><div><br></div><div><i>e=
num Flags { ENABLE_LOGGING =3D 1, ENABLE_WARNING =3D 2, OTHER =3D 4, ... };=
</i></div><div><i>void f(int flags);</i></div><div><i><br></i></div><div>An=
d we can call it without defining any boolean variables.</div><div><i><br><=
/i></div><div><i>f(ENABLE_LOGGING | ENABLE_WARNING | etc...);</i></div></di=
v></blockquote><div><br></div><div>Well, if we're going to do define the en=
um values, we might as well define the bools (as true, and then use their n=
egation where the negative is needed) - that's what I meant.</div><div><br>=
</div><div>Also, I'm mostly concerned about <i>existing</i> functions which=
 already&nbsp;take bools as arguments. Certainly when you're designing an A=
PI, you could choose to have an int as a parameter and do the flags.</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_5726_2091015440.1425447024043--
------=_Part_5725_1446900003.1425447024043--

.

On Tuesday 03 March 2015 21:24:40 Leo Heinsaar wrote:
> On Wednesday, March 4, 2015 at 12:10:30 AM UTC+4, David Rodr=C3=ADguez Ib=
eas
>=20
> wrote:
> > If I understand it correctly you are asking for the compiler to pick th=
e
> > name from the declaration of the function and allow it as a boolean 'tr=
ue'
> > at the call site.
>=20
> No, definitely not by picking up the name - just the type. This has been
> brought up in many other replies below - sorry folks for being unclear:
> names should be irrelevant. Simply my example was what one would write in
> real code.

Then I'm completely lost.

Given the following function declaration
 void f(bool, bool, bool);

How would your proposal know that the first argument is about debugging, th=
e=20
second about warnings and the third about fatal errors? There needs to be a=
=20
declaration somewhere of something, but I didn't understand where or what.

--=20
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

--=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/.

.

------=_Part_5800_334565548.1425447533729
Content-Type: multipart/alternative;
 boundary="----=_Part_5801_930977390.1425447533729"

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

On Wednesday, March 4, 2015 at 9:31:26 AM UTC+4, Thiago Macieira wrote:
>
> On Tuesday 03 March 2015 21:24:40 Leo Heinsaar wrote:=20
> > On Wednesday, March 4, 2015 at 12:10:30 AM UTC+4, David Rodr=C3=ADguez =
Ibeas=20
> >=20
> > wrote:=20
> > > If I understand it correctly you are asking for the compiler to pick=
=20
> the=20
> > > name from the declaration of the function and allow it as a boolean=
=20
> 'true'=20
> > > at the call site.=20
> >=20
> > No, definitely not by picking up the name - just the type. This has bee=
n=20
> > brought up in many other replies below - sorry folks for being unclear:=
=20
> > names should be irrelevant. Simply my example was what one would write=
=20
> in=20
> > real code.=20
>
> Then I'm completely lost.=20
>
> Given the following function declaration=20
>         void f(bool, bool, bool);=20
>
> How would your proposal know that the first argument is about debugging,=
=20
> the=20
> second about warnings and the third about fatal errors? There needs to be=
=20
> a=20
> declaration somewhere of something, but I didn't understand where or what=
..=20
>

From the function definition - there you're obviously using the boolean=20
arguments (if not, there's not much harm), so they obviously have names,=20
which will provide the meaning. Or I'm missing something?

--=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/.

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

<div dir=3D"ltr">On Wednesday, March 4, 2015 at 9:31:26 AM UTC+4, Thiago Ma=
cieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Tuesday 03 Mar=
ch 2015 21:24:40 Leo Heinsaar wrote:
<br>&gt; On Wednesday, March 4, 2015 at 12:10:30 AM UTC+4, David Rodr=C3=AD=
guez Ibeas
<br>&gt;=20
<br>&gt; wrote:
<br>&gt; &gt; If I understand it correctly you are asking for the compiler =
to pick the
<br>&gt; &gt; name from the declaration of the function and allow it as a b=
oolean 'true'
<br>&gt; &gt; at the call site.
<br>&gt;=20
<br>&gt; No, definitely not by picking up the name - just the type. This ha=
s been
<br>&gt; brought up in many other replies below - sorry folks for being unc=
lear:
<br>&gt; names should be irrelevant. Simply my example was what one would w=
rite in
<br>&gt; real code.
<br>
<br>Then I'm completely lost.
<br>
<br>Given the following function declaration
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;void f(bool, bool, bool=
);
<br>
<br>How would your proposal know that the first argument is about debugging=
, the=20
<br>second about warnings and the third about fatal errors? There needs to =
be a=20
<br>declaration somewhere of something, but I didn't understand where or wh=
at.
<br></blockquote><div><br></div><div>From the function definition - there y=
ou're obviously using the boolean arguments (if not, there's not much harm)=
, so they obviously have names, which will provide the meaning. Or I'm miss=
ing something?</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_5801_930977390.1425447533729--
------=_Part_5800_334565548.1425447533729--

.

------=_Part_5802_1198884969.1425447837824
Content-Type: multipart/alternative;
 boundary="----=_Part_5803_1968097829.1425447837824"

------=_Part_5803_1968097829.1425447837824
Content-Type: text/plain; charset=UTF-8


>
> So, is this legal?
>
> bool *foo = nullptr;
> function(foo = &enableLogging, enableWarnings);
>

Nope. Only when parameters are bools.


> If so... what's the lifetime of these magical identifiers? After the
> function call, is 'foo' pointing to real memory?
>

Not thought through, but first thought is: to be the shortest scope.


>
> You are suggesting that the compiler should create magical identifiers
> that magically fill themselves with values, without having ever been
> defined. But only in function argument lists. And only where that
> identifier name matches the corresponding parameter. And only when the type
> is a bool.
>

Exactly - except for "without having ever been defined": they *are* defined,
just implicitly, by the compiler, right above the function call.


> Isn't that way to special-case to bother standardizing? I understand the
> readability improvements, for these certain cases.
>

Possibly. That's why we're discussing it...

--

---
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_5803_1968097829.1425447837824
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>So, is this legal?<br><br>bool *foo =3D nullptr;<br>function(foo =
=3D &amp;enableLogging, enableWarnings);<br></div></div></blockquote><div><=
br></div><div>Nope. Only when parameters are bools.&nbsp;</div><div>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>If =
so... what's the lifetime of these magical identifiers? After the function =
call, is 'foo' pointing to real memory?<br></div></div></blockquote><div><b=
r></div><div>Not thought through, but first thought is: to be the shortest =
scope.</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;"><=
div dir=3D"ltr"><div><br>You are suggesting that the compiler should create=
 magical identifiers=20
that magically fill themselves with values, without having ever been=20
defined. But only in function argument lists. And only where that=20
identifier name matches the corresponding parameter. And only when the type=
 is a bool.<br></div></div></blockquote><div><br></div><div>Exactly - excep=
t for "without having ever been defined": they <i>are</i>&nbsp;defined, jus=
t implicitly, by the compiler, right above the function call.</div><div>&nb=
sp;</div><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"><div=
>Isn't that way to special-case to bother standardizing? I understand the r=
eadability improvements, for these certain cases.<br></div></div></blockquo=
te><div><br></div><div>Possibly. That's why we're discussing it...&nbsp;</d=
iv></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_5803_1968097829.1425447837824--
------=_Part_5802_1198884969.1425447837824--

.

------=_Part_4255_1217745318.1425453111928
Content-Type: multipart/alternative;
 boundary="----=_Part_4256_1126403716.1425453111928"

------=_Part_4256_1126403716.1425453111928
Content-Type: text/plain; charset=UTF-8


>
> You are suggesting that the compiler should create magical identifiers
>> that magically fill themselves with values, without having ever been
>> defined. But only in function argument lists. And only where that
>> identifier name matches the corresponding parameter. And only when the type
>> is a bool.
>>
>
> Exactly - except for "without having ever been defined": they *are* defined,
> just implicitly, by the compiler, right above the function call.
>

CORRECTION: Also except for "*only where that identifier name matches the
corresponding parameter*". Names are irrelevant, as noted.

--

---
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_4256_1126403716.1425453111928
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>You are s=
uggesting that the compiler should create magical identifiers=20
that magically fill themselves with values, without having ever been=20
defined. But only in function argument lists. And only where that=20
identifier name matches the corresponding parameter. And only when the type=
 is a bool.<br></div></div></blockquote><div><br></div><div>Exactly - excep=
t for "without having ever been defined": they <i>are</i>&nbsp;defined, jus=
t implicitly, by the compiler, right above the function call.</div></div></=
blockquote><div><br></div><div>CORRECTION: Also except for "<b>only where t=
hat identifier name matches the corresponding parameter</b>". Names are irr=
elevant, as noted.</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_4256_1126403716.1425453111928--
------=_Part_4255_1217745318.1425453111928--

.

On Tuesday 03 March 2015 21:38:53 Leo Heinsaar wrote:
> On Wednesday, March 4, 2015 at 9:31:26 AM UTC+4, Thiago Macieira wrote:
> > On Tuesday 03 March 2015 21:24:40 Leo Heinsaar wrote:
> > > No, definitely not by picking up the name - just the type. This has been
> > > brought up in many other replies below - sorry folks for being unclear:
> > > names should be irrelevant. Simply my example was what one would write

You said "names should be irrelevant"

> > Then I'm completely lost.
> >
> > Given the following function declaration
> >
> >         void f(bool, bool, bool);
> >
> > How would your proposal know that the first argument is about debugging,
> > the
> > second about warnings and the third about fatal errors? There needs to be
> > a
> > declaration somewhere of something, but I didn't understand where or what.
>
> From the function definition - there you're obviously using the boolean
> arguments (if not, there's not much harm), so they obviously have names,
> which will provide the meaning. Or I'm missing something?

The names are irrelevant. Given the function signature above, how would I use
proposal you made?

--
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_5955_2128757933.1425459127741
Content-Type: multipart/alternative;
 boundary="----=_Part_5956_957020911.1425459127741"

------=_Part_5956_957020911.1425459127741
Content-Type: text/plain; charset=UTF-8


>
> You said "names should be irrelevant"
>
> > > Then I'm completely lost.
> > >
> > > Given the following function declaration
> > >
> > >         void f(bool, bool, bool);
> > >
>


> The names are irrelevant. Given the function signature above, how would I
> use
> proposal you made?
>

Let's say the definition of the function is:

void f(bool enableL, bool enableW, bool enableE)
{
       // using some or all of enableL, enableW, enableE
}

And you want to call it in another function g(), you do the following:

void g()
{
   f(enableLogging, enableWarnings, enableErrors);
}

Which translates (i.e. is equivalent) to:

void g()
{
  const bool enableLogging    = true;
  const bool enableWarnings  = true;
  const bool enableErrors       = true;

  f(enableLogging, enableWarnings, enableErrors);
}

Wouldn't such an equivalence be possible to implement?

--

---
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_5956_957020911.1425459127741
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">You said "nam=
es should be irrelevant"
<br>
<br>&gt; &gt; Then I'm completely lost.
<br>&gt; &gt;=20
<br>&gt; &gt; Given the following function declaration
<br>&gt; &gt;=20
<br>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; void f(bool, bool, bool);
<br>&gt; &gt; <br></blockquote><div>&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">The names are irrelevant. Given the function signature ab=
ove, how would I use=20
<br>proposal you made?
<br></blockquote><div><br></div><div>Let's say the definition of the functi=
on is:</div><div><br></div><div>void f(bool enableL, bool enableW, bool ena=
bleE)<br></div><div>{</div><div>&nbsp; &nbsp; &nbsp; &nbsp;// using some or=
 all of enableL, enableW, enableE</div><div>}</div><div><br></div><div>And =
you want to call it in another function g(), you do the following:</div><di=
v><br></div><div>void g()</div><div>{</div><div>&nbsp; &nbsp;f(enableLoggin=
g, enableWarnings, enableErrors);</div><div>}</div><div><br></div><div>Whic=
h translates (i.e. is equivalent) to:</div><div><br></div><div>void g()</di=
v><div>{</div><div>&nbsp; const bool enableLogging &nbsp; &nbsp;=3D true;</=
div><div>&nbsp; const bool enableWarnings &nbsp;=3D true;</div><div>&nbsp; =
const bool enableErrors &nbsp; &nbsp; &nbsp; =3D true;</div><div><br></div>=
<div>&nbsp; f(enableLogging, enableWarnings, enableErrors);</div><div>}</di=
v><div><br></div><div>Wouldn't such an equivalence be possible to implement=
?</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_5956_957020911.1425459127741--
------=_Part_5955_2128757933.1425459127741--

.

And if you instead called f with:

f(stop_complaining, format_harddisk, exit_program);
what would happen then?

/Peter

On Wed, Mar 4, 2015 at 9:52 AM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
>> You said "names should be irrelevant"
>>
>> > > Then I'm completely lost.
>> > >
>> > > Given the following function declaration
>> > >
>> > >         void f(bool, bool, bool);
>> > >
>
>
>>
>> The names are irrelevant. Given the function signature above, how would I
>> use
>> proposal you made?
>
>
> Let's say the definition of the function is:
>
> void f(bool enableL, bool enableW, bool enableE)
> {
>        // using some or all of enableL, enableW, enableE
> }
>
> And you want to call it in another function g(), you do the following:
>
> void g()
> {
>    f(enableLogging, enableWarnings, enableErrors);
> }
>
> Which translates (i.e. is equivalent) to:
>
> void g()
> {
>   const bool enableLogging    = true;
>   const bool enableWarnings  = true;
>   const bool enableErrors       = true;
>
>   f(enableLogging, enableWarnings, enableErrors);
> }
>
> Wouldn't such an equivalence be possible to implement?
>
> --
>
> ---
> 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_5346_443538981.1425468888171
Content-Type: multipart/alternative;
 boundary="----=_Part_5347_643914930.1425468888171"

------=_Part_5347_643914930.1425468888171
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 4, 2015 at 3:06:30 PM UTC+4, Peter Koch Larsen wrote:
>
> And if you instead called f with:
>
> f(stop_complaining, format_harddisk, exit_program);
> what would happen then?
>
> /Peter
>

Then that would at least be funny, whereas f(false, true, true) is
annoyingly cryptic (and very widespread) code.

But more seriously, because of the proposed equivalence (of defining const
bool variables right above the function call) that's like asking: what if
you define variables with non-matching meanings and use them in the call
site. The answer is: we can do that even now, but we simply don't.

--

---
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_5347_643914930.1425468888171
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 4, 2015 at 3:06:30 PM UTC+4, Peter Koc=
h Larsen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">And if you inst=
ead called f with:
<br>
<br>f(stop_complaining, format_harddisk, exit_program);
<br>what would happen then?
<br>
<br>/Peter
<br></blockquote><div><br></div><div>Then that would at least be funny, whe=
reas f(false, true, true) is annoyingly cryptic (and very widespread) code.=
</div><div><br></div><div>But more seriously, because of the proposed equiv=
alence (of defining const bool variables right above the function call) tha=
t's like asking: what if you define variables with non-matching meanings an=
d use them in the call site. The answer is: we can do that even now, but we=
 simply don't.</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_5347_643914930.1425468888171--
------=_Part_5346_443538981.1425468888171--

.

What I was trying to hint at is that in effect your  names are
meaningless. So having anything that resembles a name will have the
effect of passing true to the function.
So:

bool enableLogging = ...;
bool enableWarning = ...;
....
f(enableLogging,enableWarnings);

That call would succeed instead of giving a compiler error. Not good!

/Peter

On Wed, Mar 4, 2015 at 12:34 PM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> On Wednesday, March 4, 2015 at 3:06:30 PM UTC+4, Peter Koch Larsen wrote:
>>
>> And if you instead called f with:
>>
>> f(stop_complaining, format_harddisk, exit_program);
>> what would happen then?
>>
>> /Peter
>
>
> Then that would at least be funny, whereas f(false, true, true) is
> annoyingly cryptic (and very widespread) code.
>
> But more seriously, because of the proposed equivalence (of defining const
> bool variables right above the function call) that's like asking: what if
> you define variables with non-matching meanings and use them in the call
> site. The answer is: we can do that even now, but we simply don't.
>
> --
>
> ---
> 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_531_9517456.1425484784623
Content-Type: multipart/alternative;
 boundary="----=_Part_532_1046093114.1425484784623"

------=_Part_532_1046093114.1425484784623
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 4, 2015 at 12:43:57 AM UTC-5, Leo Heinsaar wrote:
>
> So, is this legal?
>>
>> bool *foo = nullptr;
>> function(foo = &enableLogging, enableWarnings);
>>
>
> Nope. Only when parameters are bools.
>

OK, how about:

function((foo = &enableLogging) == NULL, enableWarnings);

My point is that you can take these identifiers and perform all kinds of
operations on them.


>
>
>> If so... what's the lifetime of these magical identifiers? After the
>> function call, is 'foo' pointing to real memory?
>>
>
> Not thought through, but first thought is: to be the shortest scope.
>
>
>>
>> You are suggesting that the compiler should create magical identifiers
>> that magically fill themselves with values, without having ever been
>> defined. But only in function argument lists. And only where that
>> identifier name matches the corresponding parameter. And only when the type
>> is a bool.
>>
>
> Exactly - except for "without having ever been defined": they *are* defined,
> just implicitly, by the compiler, right above the function call.
>

That's what I meant by "without having ever been defined."

Lambdas may implicitly define a new type, but they have specific syntax
that makes it clear that this definition is happening. That syntax is
plainly visible at the site of the definition. Therefore, the lambda is
effectively just an alternate way to define a new type (and instantiate an
instance of one)

What you're talking about is not merely implicit; the definition of these
local variables is *invisible* to the user. That's bad.

If I ask my IDE to take me to their definition, where should it go? The
function's parameter list? Because that's not a definition; at least, it's
not a definition within my local scope. Which is where those variables live.


>
>
>> Isn't that way to special-case to bother standardizing? I understand the
>> readability improvements, for these certain cases.
>>
>
> Possibly. That's why we're discussing it...
>

Yes, and I'm saying that it imposes far too much of a burden (both on the
standard and the compiler) for such a specific, minor gain.

--

---
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_532_1046093114.1425484784623
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 4, 2015 at 12:43:57 AM UTC-5, =
Leo Heinsaar wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>So, is =
this legal?<br><br>bool *foo =3D nullptr;<br>function(foo =3D &amp;enableLo=
gging, enableWarnings);<br></div></div></blockquote><div><br></div><div>Nop=
e. Only when parameters are bools.</div></div></blockquote><div><br>OK, how=
 about:<br><br>function((foo =3D &amp;enableLogging) =3D=3D NULL, enableWar=
nings);<br><br>My point is that you can take these identifiers and perform =
all kinds of operations on them.<br>&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>If so... what's the lifetime of thes=
e magical identifiers? After the function call, is 'foo' pointing to real m=
emory?<br></div></div></blockquote><div><br></div><div>Not thought through,=
 but first thought is: to be the shortest scope.</div><div>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>You are sugge=
sting that the compiler should create magical identifiers=20
that magically fill themselves with values, without having ever been=20
defined. But only in function argument lists. And only where that=20
identifier name matches the corresponding parameter. And only when the type=
 is a bool.<br></div></div></blockquote><div><br></div><div>Exactly - excep=
t for "without having ever been defined": they <i>are</i>&nbsp;defined, jus=
t implicitly, by the compiler, right above the function call.</div></div></=
blockquote><div><br>That's what I meant by "without having ever been define=
d."<br><br>Lambdas may implicitly define a new type, but they have specific=
 syntax that makes it clear that this definition is happening. That syntax =
is plainly visible at the site of the definition. Therefore, the lambda is =
effectively just an alternate way to define a new type (and instantiate an =
instance of one)<br><br>What you're talking about is not merely implicit; t=
he definition of these local variables is <i>invisible</i> to the user. Tha=
t's bad.<br><br>If I ask my IDE to take me to their definition, where shoul=
d it go? The function's parameter list? Because that's not a definition; at=
 least, it's not a definition within my local scope. Which is where those v=
ariables live.<br>&nbsp;<br></div><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"><div>&nbsp;</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div>Isn't that way to special-case to bother standar=
dizing? I understand the readability improvements, for these certain cases.=
<br></div></div></blockquote><div><br></div><div>Possibly. That's why we're=
 discussing it...&nbsp;</div></div></blockquote><div><br>Yes, and I'm sayin=
g that it imposes far too much of a burden (both on the standard and the co=
mpiler) for such a specific, minor gain.<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_532_1046093114.1425484784623--
------=_Part_531_9517456.1425484784623--

.

------=_Part_1660_1146951070.1425485020603
Content-Type: multipart/alternative;
 boundary="----=_Part_1661_993418018.1425485020603"

------=_Part_1661_993418018.1425485020603
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 4, 2015 at 3:52:07 AM UTC-5, Leo Heinsaar wrote:
>
> You said "names should be irrelevant"
>>
>> > > Then I'm completely lost.
>> > >
>> > > Given the following function declaration
>> > >
>> > >         void f(bool, bool, bool);
>> > >
>>
>
>
>> The names are irrelevant. Given the function signature above, how would I
>> use
>> proposal you made?
>>
>
> Let's say the definition of the function is:
>
> void f(bool enableL, bool enableW, bool enableE)
> {
>        // using some or all of enableL, enableW, enableE
> }
>
> And you want to call it in another function g(), you do the following:
>
> void g()
> {
>    f(enableLogging, enableWarnings, enableErrors);
> }
>
> Which translates (i.e. is equivalent) to:
>
> void g()
> {
>   const bool enableLogging    = true;
>   const bool enableWarnings  = true;
>   const bool enableErrors       = true;
>
>   f(enableLogging, enableWarnings, enableErrors);
> }
>
> Wouldn't such an equivalence be possible to implement?
>

I think you misunderstood what he was saying about the whole "names are
irrelevant" comment.

Yes, function definition arguments must have names, or else the function
can't actually do anything with the parameter. However, function
definitions are not necessarily in the same translation unit as the call
site.

So you could have 'void f(bool, bool, bool);' in a header somewhere. That's
all my translation unit sees.

So how can it transform 'f(enableLogging, enableWarnings, enableErrors);'
into something reasonable, when the compiler *never* saw any of those
parameter names?

So yes, names are very relevant for your concept.

--

---
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_1661_993418018.1425485020603
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 4, 2015 at 3:52:07 AM UTC-5, Leo Heins=
aar 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"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">You said "names should be irrelevant"
<br>
<br>&gt; &gt; Then I'm completely lost.
<br>&gt; &gt;=20
<br>&gt; &gt; Given the following function declaration
<br>&gt; &gt;=20
<br>&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; void f(bool, bool, bool);
<br>&gt; &gt; <br></blockquote><div>&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex">The names are irrelevant. Given the function signature above, =
how would I use=20
<br>proposal you made?
<br></blockquote><div><br></div><div>Let's say the definition of the functi=
on is:</div><div><br></div><div>void f(bool enableL, bool enableW, bool ena=
bleE)<br></div><div>{</div><div>&nbsp; &nbsp; &nbsp; &nbsp;// using some or=
 all of enableL, enableW, enableE</div><div>}</div><div><br></div><div>And =
you want to call it in another function g(), you do the following:</div><di=
v><br></div><div>void g()</div><div>{</div><div>&nbsp; &nbsp;f(enableLoggin=
g, enableWarnings, enableErrors);</div><div>}</div><div><br></div><div>Whic=
h translates (i.e. is equivalent) to:</div><div><br></div><div>void g()</di=
v><div>{</div><div>&nbsp; const bool enableLogging &nbsp; &nbsp;=3D true;</=
div><div>&nbsp; const bool enableWarnings &nbsp;=3D true;</div><div>&nbsp; =
const bool enableErrors &nbsp; &nbsp; &nbsp; =3D true;</div><div><br></div>=
<div>&nbsp; f(enableLogging, enableWarnings, enableErrors);</div><div>}</di=
v><div><br></div><div>Wouldn't such an equivalence be possible to implement=
?</div></div></blockquote><div><br>I think you misunderstood what he was sa=
ying about the whole "names are irrelevant" comment.<br><br>Yes, function d=
efinition arguments must have names, or else the function can't actually do=
 anything with the parameter. However, function definitions are not necessa=
rily in the same translation unit as the call site.<br><br>So you could hav=
e 'void f(bool, bool, bool);' in a header somewhere. That's all my translat=
ion unit sees.<br><br>So how can it transform 'f(enableLogging, enableWarni=
ngs, enableErrors);' into something reasonable, when the compiler <i>never<=
/i> saw any of those parameter names?<br><br>So yes, names are very relevan=
t for your concept.<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_1661_993418018.1425485020603--
------=_Part_1660_1146951070.1425485020603--

.

How would you parse:
using enableLogging=int;
using enableWarnings=float;
void function(enableLogging,enableWarnings);

On 3/3/15, Leo Heinsaar <leoheinsaar@gmail.com> wrote:
> For a function taking Boolean parameters:
>
> function(bool enableLogging, bool enableWarnings);
>
> wouldn't it be useful to be able to call it thus:
>
> function(enableLogging, enableWarnings);
>
> (i.e. without explicitly defining enableLogging and enableWarnings prior to
>
> the call) and having it be equivalent to:
>
> const bool enableLogging = true;
> const bool enableWarnings = true;
> function(enableLogging, enableWarnings);
>
> This would allow us to:
> 1) Eliminate irritating code like: function(true, true, false, true, false,
>
> false);
> 2) Save code space for not having to define Boolean variables.
>
> Leo
>
> --
>
> ---
> 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 Wednesday 04 March 2015 00:52:07 Leo Heinsaar wrote:
> void f(bool enableL, bool enableW, bool enableE)
> {
>        // using some or all of enableL, enableW, enableE
> }
>
> And you want to call it in another function g(), you do the following:
>
> void g()
> {
>    f(enableLogging, enableWarnings, enableErrors);
> }
>
> Which translates (i.e. is equivalent) to:
>
> void g()
> {
>   const bool enableLogging    = true;
>   const bool enableWarnings  = true;
>   const bool enableErrors       = true;
>
>   f(enableLogging, enableWarnings, enableErrors);
> }
>
> Wouldn't such an equivalence be possible to implement?

Anything is possible.

I think it's a bad idea to do this. Reasons:

1) major surgery to compilers code paths that try to determine what identifiers
are valid and in what context

2) extremely limited benefit

3) too error prone:

extern bool globalEnableLogging;
void g()
{
    f(globalEnableLoging, enableWarnings, !enableErrors);
}



--
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_6886_884701168.1425538100240
Content-Type: multipart/alternative;
 boundary="----=_Part_6887_2143242395.1425538100240"

------=_Part_6887_2143242395.1425538100240
Content-Type: text/plain; charset=UTF-8


>
> > void g()
> > {
> >   const bool enableLogging    = true;
> >   const bool enableWarnings  = true;
> >   const bool enableErrors       = true;
> >
> >   f(enableLogging, enableWarnings, enableErrors);
> > }
> >
> > Wouldn't such an equivalence be possible to implement?
>
> Anything is possible.
>
> I think it's a bad idea to do this. Reasons:
>
> 1) major surgery to compilers code paths that try to determine what
> identifiers
> are valid and in what context
>
> 2) extremely limited benefit
>
> 3) too error prone:
>
> extern bool globalEnableLogging;
> void g()
> {
>     f(globalEnableLoging, enableWarnings, !enableErrors);
> }


Okay, right. This is definitely not a feature for which it's worth dong a
major surgery in a compiler, especially if it can introduce errors. I
thought to toss the idea around in case it turned out it's something  very
easy to implement and absolutely not error prone.

Thanks to all for the thoughts.

--

---
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_6887_2143242395.1425538100240
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; void g()
<br>&gt; {
<br>&gt; &nbsp; const bool enableLogging &nbsp; &nbsp;=3D true;
<br>&gt; &nbsp; const bool enableWarnings &nbsp;=3D true;
<br>&gt; &nbsp; const bool enableErrors &nbsp; &nbsp; &nbsp; =3D true;
<br>&gt;=20
<br>&gt; &nbsp; f(enableLogging, enableWarnings, enableErrors);
<br>&gt; }
<br>&gt;=20
<br>&gt; Wouldn't such an equivalence be possible to implement?
<br>
<br>Anything is possible.
<br>
<br>I think it's a bad idea to do this. Reasons:
<br>
<br>1) major surgery to compilers code paths that try to determine what ide=
ntifiers=20
<br>are valid and in what context
<br>
<br>2) extremely limited benefit
<br>
<br>3) too error prone:
<br>
<br>extern bool globalEnableLogging;
<br>void g()
<br>{
<br>&nbsp; &nbsp; f(globalEnableLoging, enableWarnings, !enableErrors);
<br>}&nbsp;</blockquote><div><br></div><div>Okay, right. This is definitely=
 not a feature for which it's worth dong a major surgery in a compiler, esp=
ecially if it can introduce errors. I thought to toss the idea around in ca=
se it turned out it's something &nbsp;very easy to implement and absolutely=
 not error prone.</div><div><br></div><div>Thanks to all for the thoughts.<=
/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_6887_2143242395.1425538100240--
------=_Part_6886_884701168.1425538100240--

.

------=_Part_7111_1964332037.1425540799906
Content-Type: multipart/alternative;
 boundary="----=_Part_7112_1262440528.1425540799906"

------=_Part_7112_1262440528.1425540799906
Content-Type: text/plain; charset=UTF-8

Actually, I just figured out - and wanted to share - a way to solve the
problem of *function(true, false, true, false, true)* with a very simple
trick without changing anything at all in the language:

*constexpr bool operator""_yes(const char*, size_t) { return true; }*
*constexpr bool operator""_no(const char*, size_t)  { return false; }*

Now I can simply write:

*f("enable logging"_yes, "enable warnings"_no, "enable errors"_yes, "tell
grandma I'm gonna be late tonight"_yes);*

(Perhaps it would be a good idea to make those _yes and _no UDLs standard
instead?)

--

---
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_7112_1262440528.1425540799906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Actually, I just figured out - and wanted to share - a way=
 to solve the problem of <b>function(true, false, true, false, true)</b> wi=
th a very simple trick without changing anything at all in the language:<di=
v><br></div><div><div><b>constexpr bool operator""_yes(const char*, size_t)=
 { return true; }</b></div><div><b>constexpr bool operator""_no(const char*=
, size_t) &nbsp;{ return false; }</b></div><div><br></div><div>Now I can si=
mply write:</div><div><br></div><div><b>f("enable logging"_yes, "enable war=
nings"_no, "enable errors"_yes, "tell grandma I'm gonna be late tonight"_ye=
s);</b></div><div><br></div><div>(Perhaps it would be a good idea to make t=
hose _yes and _no UDLs standard instead?)</div><div><br></div></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_7112_1262440528.1425540799906--
------=_Part_7111_1964332037.1425540799906--

.

--001a1137c7f40ce398051085a515
Content-Type: text/plain; charset=UTF-8

On 5 March 2015 at 01:33, Leo Heinsaar <leoheinsaar@gmail.com> wrote:

> *constexpr bool operator""_yes(const char*, size_t) { return true; }*
> *constexpr bool operator""_no(const char*, size_t)  { return false; }*
>
> Now I can simply write:
>
> *f("enable logging"_yes, "enable warnings"_no, "enable errors"_yes, "tell
> grandma I'm gonna be late tonight"_yes);*
>

Or

*f("enable errors"_yes, "tell grandma I'm gonna be late tonight"_yes, **"enable
logging"_yes, "enable warnings"_no,**);*


> (Perhaps it would be a good idea to make those _yes and _no UDLs standard
> instead?)
>

Or perhaps not.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

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

<div dir=3D"ltr">On 5 March 2015 at 01:33, Leo Heinsaar <span dir=3D"ltr">&=
lt;<a href=3D"mailto:leoheinsaar@gmail.com" target=3D"_blank">leoheinsaar@g=
mail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div><b>constexpr bool =
operator&quot;&quot;_yes(const char*, size_t) { return true; }</b></div><di=
v><b>constexpr bool operator&quot;&quot;_no(const char*, size_t) =C2=A0{ re=
turn false; }</b></div><div><br></div><div>Now I can simply write:</div><di=
v><br></div><div><b>f(&quot;enable logging&quot;_yes, &quot;enable warnings=
&quot;_no, &quot;enable errors&quot;_yes, &quot;tell grandma I&#39;m gonna =
be late tonight&quot;_yes);</b></div></div></div></blockquote><div><br></di=
v><div>Or</div><div><br></div><div><div style=3D"font-size:13px"><b>f(&quot=
;enable errors&quot;_yes, &quot;tell grandma I&#39;m gonna be late tonight&=
quot;_yes,=C2=A0</b><b>&quot;enable logging&quot;_yes, &quot;enable warning=
s&quot;_no,</b><b>);</b></div><div style=3D"font-size:13px"><span style=3D"=
font-size:small">=C2=A0</span><br></div></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><div>(Perhaps it would be a good idea to make those _yes and _no UDLs =
standard instead?)<br></div></div></blockquote><div><br></div><div>Or perha=
ps not.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;=
:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</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 />

--001a1137c7f40ce398051085a515--

.

------=_Part_7328_1100212580.1425541551313
Content-Type: multipart/alternative;
 boundary="----=_Part_7329_1438631390.1425541551313"

------=_Part_7329_1438631390.1425541551313
Content-Type: text/plain; charset=UTF-8

On Thursday, March 5, 2015 at 11:37:50 AM UTC+4, Nevin ":-)" Liber wrote:
>
> On 5 March 2015 at 01:33, Leo Heinsaar <leohe...@gmail.com <javascript:>>
> wrote:
>
>> *constexpr bool operator""_yes(const char*, size_t) { return true; }*
>> *constexpr bool operator""_no(const char*, size_t)  { return false; }*
>>
>> Now I can simply write:
>>
>> *f("enable logging"_yes, "enable warnings"_no, "enable errors"_yes, "tell
>> grandma I'm gonna be late tonight"_yes);*
>>
>
> Or
>
> *f("enable errors"_yes, "tell grandma I'm gonna be late tonight"_yes, **"enable
> logging"_yes, "enable warnings"_no,**);*
>

Well, again - that is like saying what if you mix up and write *true* where
there needs to be *false* in your existing code.

Actually, the trick is a bad idea because it'll compile even if you forget
the suffixes; opened the champagne too soon.

>

--

---
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_7329_1438631390.1425541551313
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 5, 2015 at 11:37:50 AM UTC+4, Nevin ":-=
)" Liber 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 5 March 2015 at 01:33, Leo Heinsaar <span dir=3D"ltr">&lt;<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CRQ901Msp68J" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">leohe...@gmail.com</a>&gt;</spa=
n> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l=
tr"><div><div><b>constexpr bool operator""_yes(const char*, size_t) { retur=
n true; }</b></div><div><b>constexpr bool operator""_no(const char*, size_t=
) &nbsp;{ return false; }</b></div><div><br></div><div>Now I can simply wri=
te:</div><div><br></div><div><b>f("enable logging"_yes, "enable warnings"_n=
o, "enable errors"_yes, "tell grandma I'm gonna be late tonight"_yes);</b><=
/div></div></div></blockquote><div><br></div><div>Or</div><div><br></div><d=
iv><div style=3D"font-size:13px"><b>f("enable errors"_yes, "tell grandma I'=
m gonna be late tonight"_yes,&nbsp;</b><b>"enable logging"_yes, "enable war=
nings"_no,</b><b>);</b></div></div></div></div></div></blockquote><div><br>=
</div><div>Well, again - that is like saying what if you mix up and write <=
b>true</b>&nbsp;where there needs to be <b>false</b>&nbsp;in your existing =
code.</div><div>&nbsp;</div><div>Actually, the trick is a bad idea because =
it'll compile even if you forget the suffixes; opened the champagne too soo=
n.</div><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"><div>
</div></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_7329_1438631390.1425541551313--
------=_Part_7328_1100212580.1425541551313--

.

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

It's not only a bad idea because the literal would implicitly convert to
'true' (that was what you were looking for in the first place) but because
you are making errors harder to detect. If you see a combination
'f(true,false,true)' chances are that you will go look the definition (or
the declaration) to check what each argument means.  If you read:

f("enable errors"_yes, "enable warnings"_no, "something else"_yes)

chances are that you will be more inclined to believe what you read. You
have not improved anything, the code is not safe the compiler is not
checking that the arguments are in the right order. On the other hand, you
are feeding potentially misleading information to the maintainer of the
code, doing them a disservice.

I was not too fond of the original idea, when I thought that it was about
the compiler picking up the name of the argument from the
declaration/definition and allowing the use, but this is more dangerous
than that.

   David

On Thu, Mar 5, 2015 at 2:45 AM, Leo Heinsaar <leoheinsaar@gmail.com> wrote:

> On Thursday, March 5, 2015 at 11:37:50 AM UTC+4, Nevin ":-)" Liber wrote:
>>
>> On 5 March 2015 at 01:33, Leo Heinsaar <leohe...@gmail.com> wrote:
>>
>>> *constexpr bool operator""_yes(const char*, size_t) { return true; }*
>>> *constexpr bool operator""_no(const char*, size_t)  { return false; }*
>>>
>>> Now I can simply write:
>>>
>>> *f("enable logging"_yes, "enable warnings"_no, "enable errors"_yes,
>>> "tell grandma I'm gonna be late tonight"_yes);*
>>>
>>
>> Or
>>
>> *f("enable errors"_yes, "tell grandma I'm gonna be late tonight"_yes, **"enable
>> logging"_yes, "enable warnings"_no,**);*
>>
>
> Well, again - that is like saying what if you mix up and write *true* where
> there needs to be *false* in your existing code.
>
> Actually, the trick is a bad idea because it'll compile even if you forget
> the suffixes; opened the champagne too soon.
>
>>   --
>
> ---
> 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/.

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

<div dir=3D"ltr">It&#39;s not only a bad idea because the literal would imp=
licitly convert to &#39;true&#39; (that was what you were looking for in th=
e first place) but because you are making errors harder to detect. If you s=
ee a combination &#39;f(true,false,true)&#39; chances are that you will go =
look the definition (or the declaration) to check what each argument means.=
=C2=A0 If you read:<div><br></div><div>f(&quot;enable errors&quot;_yes, &qu=
ot;enable warnings&quot;_no, &quot;something else&quot;_yes)</div><div><br>=
</div><div>chances are that you will be more inclined to believe what you r=
ead. You have not improved anything, the code is not safe the compiler is n=
ot checking that the arguments are in the right order. On the other hand, y=
ou are feeding potentially misleading information to the maintainer of the =
code, doing them a disservice.=C2=A0</div><div><br></div><div>I was not too=
 fond of the original idea, when I thought that it was about the compiler p=
icking up the name of the argument from the declaration/definition and allo=
wing the use, but this is more dangerous than that.</div><div><br></div><di=
v>=C2=A0 =C2=A0David</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Mar 5, 2015 at 2:45 AM, Leo Heinsaar <span dir=3D"=
ltr">&lt;<a href=3D"mailto:leoheinsaar@gmail.com" target=3D"_blank">leohein=
saar@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">On Thursday, March 5, 2015 at 11:37:50 AM UTC+4, Nevin &quot;:=
-)&quot; Liber wrote:<span class=3D""><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">On 5 March 2015 at 01:33, Leo Heinsaar <span dir=3D"ltr=
">&lt;<a rel=3D"nofollow">leohe...@gmail.com</a>&gt;</span> wrote:<br><div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div><b>c=
onstexpr bool operator&quot;&quot;_yes(const char*, size_t) { return true; =
}</b></div><div><b>constexpr bool operator&quot;&quot;_no(const char*, size=
_t) =C2=A0{ return false; }</b></div><div><br></div><div>Now I can simply w=
rite:</div><div><br></div><div><b>f(&quot;enable logging&quot;_yes, &quot;e=
nable warnings&quot;_no, &quot;enable errors&quot;_yes, &quot;tell grandma =
I&#39;m gonna be late tonight&quot;_yes);</b></div></div></div></blockquote=
><div><br></div><div>Or</div><div><br></div><div><div style=3D"font-size:13=
px"><b>f(&quot;enable errors&quot;_yes, &quot;tell grandma I&#39;m gonna be=
 late tonight&quot;_yes,=C2=A0</b><b>&quot;enable logging&quot;_yes, &quot;=
enable warnings&quot;_no,</b><b>);</b></div></div></div></div></div></block=
quote><div><br></div></span><div>Well, again - that is like saying what if =
you mix up and write <b>true</b>=C2=A0where there needs to be <b>false</b>=
=C2=A0in your existing code.</div><div>=C2=A0</div><div>Actually, the trick=
 is a bad idea because it&#39;ll compile even if you forget the suffixes; o=
pened the champagne too soon.</div><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"><div>
</div></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><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 />

--047d7bd76720d447400510971dae--

.

------=_Part_276_89764660.1425626642801
Content-Type: multipart/alternative;
 boundary="----=_Part_277_1141120426.1425626642802"

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



On Friday, March 6, 2015 at 8:28:37 AM UTC+4, David Rodr=C3=ADguez Ibeas wr=
ote:
>
> It's not only a bad idea because the literal would implicitly convert to=
=20
> 'true' (that was what you were looking for in the first place) but becaus=
e=20
> you are making errors harder to detect. If you see a combination=20
> 'f(true,false,true)' chances are that you will go look the definition (or=
=20
> the declaration) to check what each argument means.  If you read:
>
> f("enable errors"_yes, "enable warnings"_no, "something else"_yes)
>
> chances are that you will be more inclined to believe what you read. You=
=20
> have not improved anything, the code is not safe the compiler is not=20
> checking that the arguments are in the right order. On the other hand, yo=
u=20
> are feeding potentially misleading information to the maintainer of the=
=20
> code, doing them a disservice.
>

Well, I mean, in an unfamiliar code I find myself forgetting what each=20
argument was *even when I look up the definition/declaration* of an *f(true=
,=20
false, true)* call. Even when I look it up twice. (For the same reason many=
=20
don't like *.first* and *.second*.) The advantage of *f("enable=20
errors"_yes, "enable warnings"_no, "something else"_yes)*, if it worked=20
type-safely, would have been in the ability to establish that the arguments=
=20
are in the right order once we looked up the definition/declaration (often=
=20
by a simple hover on the function name in an IDE) and focus on the=20
application logic.

Anyway, many good ideas come from bad ideas. I hope this is one of them.

--=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/.

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

<div dir=3D"ltr"><br><br>On Friday, March 6, 2015 at 8:28:37 AM UTC+4, Davi=
d Rodr=C3=ADguez Ibeas wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">It's not only a bad idea because the literal would implicit=
ly convert to 'true' (that was what you were looking for in the first place=
) but because you are making errors harder to detect. If you see a combinat=
ion 'f(true,false,true)' chances are that you will go look the definition (=
or the declaration) to check what each argument means.&nbsp; If you read:<d=
iv><br></div><div>f("enable errors"_yes, "enable warnings"_no, "something e=
lse"_yes)</div><div><br></div><div>chances are that you will be more inclin=
ed to believe what you read. You have not improved anything, the code is no=
t safe the compiler is not checking that the arguments are in the right ord=
er. On the other hand, you are feeding potentially misleading information t=
o the maintainer of the code, doing them a disservice.</div></div></blockqu=
ote><div><br></div><div>Well, I mean, in an unfamiliar code I find myself f=
orgetting what each argument was <i>even when I look up the definition/decl=
aration</i>&nbsp;of an <b>f(true, false, true)</b> call. Even when I look i=
t up twice. (For the same reason many don't like <b>.first</b> and <b>.seco=
nd</b>.) The advantage of <b>f("enable errors"_yes, "enable warnings"_no, "=
something else"_yes)</b>, if it worked type-safely, would have been in the =
ability to establish that the arguments are in the right order once we look=
ed up the definition/declaration (often by a simple hover on the function n=
ame in an IDE) and focus on the application logic.</div><div><br></div><div=
>Anyway, many good ideas come from bad ideas. I hope this is one of them.</=
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_277_1141120426.1425626642802--
------=_Part_276_89764660.1425626642801--

.

------=_Part_840_997807058.1425674327492
Content-Type: multipart/alternative;
 boundary="----=_Part_841_1634286817.1425674327499"

------=_Part_841_1634286817.1425674327499
Content-Type: text/plain; charset=UTF-8

GCC 4.9.2 have extension that allow using strings in template UDLs. This
could create type safe arguments:

http://goo.gl/q3ovmV

template<char...>
  class A {};

template<typename Char, Char... T>
  constexpr  A<T...> operator"" _test() { return {}; }

void func(A<'I', '\'', 'm'>)
{

}

int main()
{
  func("I'm"_test);
  func("I am not"_test); //error
}




On Thursday, March 5, 2015 at 8:37:50 AM UTC+1, Nevin ":-)" Liber wrote:
>
> On 5 March 2015 at 01:33, Leo Heinsaar <leohe...@gmail.com <javascript:>>
> wrote:
>
>> *constexpr bool operator""_yes(const char*, size_t) { return true; }*
>> *constexpr bool operator""_no(const char*, size_t)  { return false; }*
>>
>> Now I can simply write:
>>
>> *f("enable logging"_yes, "enable warnings"_no, "enable errors"_yes, "tell
>> grandma I'm gonna be late tonight"_yes);*
>>
>
> Or
>
> *f("enable errors"_yes, "tell grandma I'm gonna be late tonight"_yes, **"enable
> logging"_yes, "enable warnings"_no,**);*
>
>
>> (Perhaps it would be a good idea to make those _yes and _no UDLs standard
>> instead?)
>>
>
> Or perhaps not.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

---
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_841_1634286817.1425674327499
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">GCC 4.9.2 have extension that allow using strings in templ=
ate UDLs. This could create type safe arguments:<br><br>http://goo.gl/q3ovm=
V<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">template</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">char</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...&gt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">class</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-by-prettify"><br><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">template</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">typename</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Char</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Char</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">constexpr</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> &nbsp;A</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">...&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">operator</span><span style=3D"color: #080;" class=3D"styled-by-prettify=
">""</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _test=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> func</span><spa=
n style=3D"color: #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">&lt;</span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">'I'</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pre=
ttify">'\''</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">'m'</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&gt;)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>&nbsp; <br></span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> main</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
; func</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #080;" class=3D"styled-by-prettify">"I'm"</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">_test</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; func</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #080;" class=3D"styled-by-prettify">"I am not"</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">_test</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//error</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br><br></span></div></code></div><br><br><br>On Thursday, March 5, 2015 at=
 8:37:50 AM UTC+1, Nevin ":-)" Liber 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 5 March 2015 at 01:33, Leo Heinsaar <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"CRQ901Msp68J" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascri=
pt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">leohe=
....@gmail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div><b>constexpr bool operator""_yes(co=
nst char*, size_t) { return true; }</b></div><div><b>constexpr bool operato=
r""_no(const char*, size_t) &nbsp;{ return false; }</b></div><div><br></div=
><div>Now I can simply write:</div><div><br></div><div><b>f("enable logging=
"_yes, "enable warnings"_no, "enable errors"_yes, "tell grandma I'm gonna b=
e late tonight"_yes);</b></div></div></div></blockquote><div><br></div><div=
>Or</div><div><br></div><div><div style=3D"font-size:13px"><b>f("enable err=
ors"_yes, "tell grandma I'm gonna be late tonight"_yes,&nbsp;</b><b>"enable=
 logging"_yes, "enable warnings"_no,</b><b>);</b></div><div style=3D"font-s=
ize:13px"><span style=3D"font-size:small">&nbsp;</span><br></div></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>(Perhaps it would be a good idea to make=
 those _yes and _no UDLs standard instead?)<br></div></div></blockquote><di=
v><br></div><div>Or perhaps not.</div></div>-- <br><div>&nbsp;Nevin ":-)" L=
iber&nbsp; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"CRQ901Msp68J" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>ne...@eviloverlord.com</a><wbr>&gt;&nbsp; (847) 691-1404</div>
</div></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_841_1634286817.1425674327499--
------=_Part_840_997807058.1425674327492--

.