------=_Part_726_99733.1395006784643
Content-Type: text/plain; charset=UTF-8

Hi Everyone

I recently made a mistake in a program where if had some code that looked
vaguely like this:

int difference_ = 0;
if ( difference > 0 )
 printf("I feel a disturbance in the force.");

It compiled fine, but didn't do as expected. It always printed the message.
Clearly disturbing.
I couldn't work out what was wrong from just looking at the code and their
was no compiler warning, even with all warning on (I assume, unless I have
a configuration error).

It turned out the problem was simply difference is an existing function and
I was testing the function pointer or something and not my local variable
difference_.
So it was like I had written
if ( printf > 0)
 do_something_dubious();

I can see why a variation of this might be useful, such as this:
if (my_function_ptr != nullptr) // Perhaps a pointer into a shared library
symbol set a runtime (e.g.. through GetProcAddress on windows).
    my_function_ptr();

but why allow if (my_function_ptr > 0 ) so easily?

No doubt a minute after posting I'll realise why this is useful, but right
now, having just been bitten by the bug, I can't see the value of it, at
least things are now.

So my question / proposal is:
Can we deprecate / make illegal these kinds of expressions i.e. relational
operators on function pointers. I'm not sure why this would ever be useful.
At the very least a warning would be good. But my question/suggestion is
why not aim to make this illegal and do it now or start the path towards it
through deprecation?

There might be some low level system code type reason to allow this, but
maybe there's other ways to perform that. If we can deprecate/disallow them
or at least consider these expressions non mainstream code warn on them
maybe this would be better than the current situation as it appears to be
right now.

Thanks

--

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

<div dir=3D"ltr"><div>Hi Everyone</div><div><br></div><div>I recently made =
a mistake in a program where if had some code that looked vaguely like this=
:</div><div><br></div><div>int difference_ =3D 0;</div><div>if ( difference=
 &gt;&nbsp;0 )</div><div>&nbsp;printf("I feel a disturbance in the force.")=
;</div><div><br></div><div>It compiled fine, but didn't do as expected. It&=
nbsp;always printed the message. Clearly disturbing.</div><div>I couldn't w=
ork out what was&nbsp;wrong from just looking at the code and their was no =
compiler warning, even&nbsp;with&nbsp;all warning&nbsp;on (I assume, unless=
 I have a configuration error).</div><div><br></div><div>It turned out the =
problem was simply difference is an existing function and I was testing the=
 function pointer or something and not my local variable difference_.</div>=
<div>So it was like I had written</div><div>if ( printf &gt; 0)</div><div>&=
nbsp;do_something_dubious();</div><div><br></div><div>I can see why a varia=
tion of this might be useful, such as this:</div><div>if (my_function_ptr !=
=3D nullptr) // Perhaps a pointer into a shared library symbol set a runtim=
e (e.g.. through GetProcAddress on windows).</div><div>&nbsp;&nbsp;&nbsp; m=
y_function_ptr();</div><div><br></div><div>but why&nbsp;allow if (my_functi=
on_ptr &gt; 0 ) so easily?</div><div><br></div><div>No doubt a minute after=
 posting I'll realise why this is useful, but right now,&nbsp;having just b=
een bitten by the bug,&nbsp;I can't see the value of it, at least things ar=
e now.</div><div><br></div><div>So my question / proposal is:</div><div><di=
v>Can we deprecate /&nbsp;make illegal these kinds of expressions i.e. rela=
tional operators on function pointers. I'm not sure&nbsp;why this would eve=
r be useful.</div><div>At the very least a warning would be good. But my qu=
estion/suggestion is why not&nbsp;aim&nbsp;to make this&nbsp;illegal and do=
 it now or start the path towards it through deprecation?</div><div><br></d=
iv><div><div>There might be some low level system code type reason to allow=
 this, but maybe there's other ways to perform that.&nbsp;If we can depreca=
te/disallow them or at least consider these expressions non mainstream code=
&nbsp;warn on them maybe this would be better than the current situation as=
 it appears to be right now.</div><div><br></div></div></div><div>Thanks</d=
iv><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_726_99733.1395006784643--

.

On 03/16/2014 10:53 PM, gmisocpp@gmail.com wrote:
> Can we deprecate / make illegal these kinds of expressions i.e.
> relational operators on function pointers. I'm not sure why this
> would ever be useful. At the very least a warning would be good. But
> my question/suggestion is why not aim to make this illegal and do it
> now or start the path towards it through deprecation?

So, you're saying applying a relational operator to
a function pointer should be ill-formed.

I agree this isn't outright misguided.

So, please write a WG21 proposal paper that shows the
necessary changes in the standard's wording,
with some rationale and examples why this is
useful.  An estimate how much code would break
is welcome, too.

I'm sure isocpp.org has instructions for writing
and submitting papers somewhere.

Thanks,
Jens

--

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

.

Am 16.03.2014 23:45, schrieb Jens Maurer:
> On 03/16/2014 10:53 PM, gmisocpp@gmail.com wrote:
>> Can we deprecate / make illegal these kinds of expressions i.e.
>> relational operators on function pointers. I'm not sure why this
>> would ever be useful. At the very least a warning would be good. But
>> my question/suggestion is why not aim to make this illegal and do it
>> now or start the path towards it through deprecation?
> So, you're saying applying a relational operator to
> a function pointer should be ill-formed.
>
> I agree this isn't outright misguided.
>
> So, please write a WG21 proposal paper that shows the
> necessary changes in the standard's wording,
> with some rationale and examples why this is
> useful.  An estimate how much code would break
> is welcome, too.
>
> I'm sure isocpp.org has instructions for writing
> and submitting papers somewhere.
>
> Thanks,
> Jens
>
Being able to sort (heterogenous/polymorphic) unordered containers on
function addresses before iterating (i.e. invoking each element) can
measurably reduce instruction cache misses and is therefore a relevant
tool for optimization. So this capability is required. If it's just the
operator that causes trouble then the OP also has to propose some
alternate way of performing this operation as otherwise we would lose
important functionality.

Miro

--

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

.

--089e0160a3d014c73a04f4c291f5
Content-Type: text/plain; charset=ISO-8859-1

Also, it makes it possible to have ordered containers (set/map) with
function pointer keys, which is useful.

I believe -Wzero-as-null-pointer-constant would give a warning in the OP's
case, at least in gcc. The warning is not for everyone, since you then need
to use nullptr everywhere, but it's quite useful. It greatly reduces the
likelihood of this kind of accident .


2014-03-17 0:14 GMT+01:00 Miro Knejp <miro@knejp.de>:

>
> Am 16.03.2014 23:45, schrieb Jens Maurer:
>
>  On 03/16/2014 10:53 PM, gmisocpp@gmail.com wrote:
>>
>>> Can we deprecate / make illegal these kinds of expressions i.e.
>>> relational operators on function pointers. I'm not sure why this
>>> would ever be useful. At the very least a warning would be good. But
>>> my question/suggestion is why not aim to make this illegal and do it
>>> now or start the path towards it through deprecation?
>>>
>> So, you're saying applying a relational operator to
>> a function pointer should be ill-formed.
>>
>> I agree this isn't outright misguided.
>>
>> So, please write a WG21 proposal paper that shows the
>> necessary changes in the standard's wording,
>> with some rationale and examples why this is
>> useful.  An estimate how much code would break
>> is welcome, too.
>>
>> I'm sure isocpp.org has instructions for writing
>> and submitting papers somewhere.
>>
>> Thanks,
>> Jens
>>
>>  Being able to sort (heterogenous/polymorphic) unordered containers on
> function addresses before iterating (i.e. invoking each element) can
> measurably reduce instruction cache misses and is therefore a relevant tool
> for optimization. So this capability is required. If it's just the operator
> that causes trouble then the OP also has to propose some alternate way of
> performing this operation as otherwise we would lose important
> functionality.
>
> Miro
>
>
> --
>
> --- 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/.

--089e0160a3d014c73a04f4c291f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Also, it makes it possible to have ordered containers (set=
/map) with function pointer keys, which is useful.<div><br></div><div>I bel=
ieve -Wzero-as-null-pointer-constant would give a warning in the OP&#39;s c=
ase, at least in gcc. The warning is not for everyone, since you then need =
to use nullptr everywhere, but it&#39;s quite useful. It greatly reduces th=
e likelihood of this kind of accident .</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-03=
-17 0:14 GMT+01:00 Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mailto:miro@=
knejp.de" target=3D"_blank">miro@knejp.de</a>&gt;</span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<br>
Am 16.03.2014 23:45, schrieb Jens Maurer:<div class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 03/16/2014 10:53 PM, <a href=3D"mailto:gmisocpp@gmail.com" target=3D"_bl=
ank">gmisocpp@gmail.com</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Can we deprecate / make illegal these kinds of expressions i.e.<br>
relational operators on function pointers. I&#39;m not sure why this<br>
would ever be useful. At the very least a warning would be good. But<br>
my question/suggestion is why not aim to make this illegal and do it<br>
now or start the path towards it through deprecation?<br>
</blockquote>
So, you&#39;re saying applying a relational operator to<br>
a function pointer should be ill-formed.<br>
<br>
I agree this isn&#39;t outright misguided.<br>
<br>
So, please write a WG21 proposal paper that shows the<br>
necessary changes in the standard&#39;s wording,<br>
with some rationale and examples why this is<br>
useful. =A0An estimate how much code would break<br>
is welcome, too.<br>
<br>
I&#39;m sure <a href=3D"http://isocpp.org" target=3D"_blank">isocpp.org</a>=
 has instructions for writing<br>
and submitting papers somewhere.<br>
<br>
Thanks,<br>
Jens<br>
<br>
</blockquote></div>
Being able to sort (heterogenous/polymorphic) unordered containers on funct=
ion addresses before iterating (i.e. invoking each element) can measurably =
reduce instruction cache misses and is therefore a relevant tool for optimi=
zation. So this capability is required. If it&#39;s just the operator that =
causes trouble then the OP also has to propose some alternate way of perfor=
ming this operation as otherwise we would lose important functionality.<spa=
n class=3D"HOEnZb"><font color=3D"#888888"><br>

<br>
Miro</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>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 />

--089e0160a3d014c73a04f4c291f5--

.

--Apple-Mail=_BF08F208-1AD6-4DA5-BA5C-2493DF0FBBEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-03-17, at 5:53 AM, gmisocpp@gmail.com wrote:

> So my question / proposal is:
> Can we deprecate / make illegal these kinds of expressions i.e. relationa=
l operators on function pointers. I'm not sure why this would ever be usefu=
l.

The result of function pointer relational comparison is implementation-defi=
ned, making it unportable but potentially the same as std::less (the portab=
le alternative) on any or most, if not all platforms. This in turn could be=
 used to sort pointers. Most probably feel that the operator should be made=
 to work properly, not deprecated.

> At the very least a warning would be good.

Indeed. The problem with your code is that the condition is always true.

GCC -Wextra gives me this:

comp.cpp:4:10: warning: ordered comparison of pointer with integer zero [-W=
extra]

This should be as much solution to this problem as the world needs.

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

--Apple-Mail=_BF08F208-1AD6-4DA5-BA5C-2493DF0FBBEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03&ndash;17, at 5:53 AM, <a href=3D"mailto:gmisocpp@gmail.com">gmisoc=
pp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><block=
quote type=3D"cite"><div dir=3D"ltr"><div>So my question / proposal is:</di=
v><div><div>Can we deprecate /&nbsp;make illegal these kinds of expressions=
 i.e. relational operators on function pointers. I'm not sure&nbsp;why this=
 would ever be useful.</div></div></div></blockquote><div><br></div><div>Th=
e result of function pointer relational comparison is implementation-define=
d, making it unportable but potentially the same as <font face=3D"Courier">=
std::less</font> (the portable alternative) on any or most, if not all plat=
forms. This in turn could be used to sort pointers. Most probably feel that=
 the operator should be made to work properly, not deprecated.</div><br><bl=
ockquote type=3D"cite"><div dir=3D"ltr"><div><div>At the very least a warni=
ng would be good.</div></div></div></blockquote><div><br></div><div>Indeed.=
 The problem with your code is that the condition is always true.</div><div=
><br></div><div>GCC -Wextra gives me this:</div><div><br></div><div><div st=
yle=3D"margin: 0px; font-size: 8px; font-family: Monaco; color: rgb(245, 24=
5, 245); background-color: rgb(0, 0, 0);">comp.cpp:4:10: warning: ordered c=
omparison of pointer with integer zero [-Wextra]</div><div><br></div><div>T=
his should be as much solution to this problem as the world needs.</div><di=
v><br></div></div></div></body></html>

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

--Apple-Mail=_BF08F208-1AD6-4DA5-BA5C-2493DF0FBBEA--

.

--001a11332d167e4a5404f4c2d716
Content-Type: text/plain; charset=ISO-8859-1

HI

On Mon, Mar 17, 2014 at 12:14 PM, Miro Knejp <miro@knejp.de> wrote:

>
> Am 16.03.2014 23:45, schrieb Jens Maurer:
>
>
>>> So, you're saying applying a relational operator to
>> a function pointer should be ill-formed.
>>
>
Yes, I'm leaning that way. And probably ++ etc. too.


>
>> I agree this isn't outright misguided.
>>
>> So, please write a WG21 proposal paper that shows the
>> necessary changes in the standard's wording,
>> with some rationale and examples why this is
>> useful.  An estimate how much code would break
>> is welcome, too.
>>
> I'll certainly consider writing some kind of rationale. I can't promise
though. If I do, l will likely do that based on my first observation that
started this thread and the subsequent replies on here that convince me (or
not) that my basic premise on this is correct, which is that certain
expressions involving function pointers aren't useful/safe to allow by
default. Assuming that premise is correct, I'm not yet sure how to control
that feature Hopefully that'll be clearer from other peoples ideas in the
ensuing discussion I hope to start.

I don't realistically expect to be able to present any believable  data as
to how much code might reasonably break from changes in this
area. Hopefully the potential breakage level (or not) will become
apparent as people discus this idea further.

Being able to sort (heterogenous/polymorphic) unordered containers on
> function addresses before iterating (i.e. invoking each element) can
> measurably reduce instruction cache misses and is therefore a relevant tool
> for optimization. So this capability is required. If it's just the operator
> that causes trouble then the OP also has to propose some alternate way of
> performing this operation as otherwise we would lose important
> functionality.
>
> Miro
>
> Yes I imagined there must be some kind of use like this when I posted. But
even now I still can't fully imagine exactly what such code would look like
and how portable one should expect such code to be by default.

Miro, or anyone, can you submit a small piece of such code that you think
should be supported? Then we could see if such code is actually portable,
mainstream, or whatever and it would be easier to see what to make of it
then.

--

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

--001a11332d167e4a5404f4c2d716
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">HI<br><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Mon, Mar 17, 2014 at 12:14 PM, Miro Knejp <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:miro@knejp.de" target=3D"_blank">miro@knejp.de</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><br>
Am 16.03.2014 23:45, schrieb Jens Maurer:<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
<br></blockquote>
So, you&#39;re saying applying a relational operator to<br>
a function pointer should be ill-formed.<br></blockquote></div></blockquote=
><div><br></div><div>Yes, I&#39;m leaning that way. And probably ++ etc. to=
o.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-l=
eft-width:1px;border-left-style:solid">
<div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid">
<br>
I agree this isn&#39;t outright misguided.<br>
<br>
So, please write a WG21 proposal paper that shows the<br>
necessary changes in the standard&#39;s wording,<br>
with some rationale and examples why this is<br>
useful. =A0An estimate how much code would break<br>
is welcome, too.<br></blockquote></div></blockquote><div>I&#39;ll=A0certain=
ly consider=A0writing some kind of rationale. I can&#39;t promise though.=
=A0If I do, l will=A0likely=A0do that based=A0on my first observation that =
started this thread=A0and=A0the subsequent replies=A0on here that=A0convinc=
e me (or not)=A0that=A0my basic premise on this is correct, which is that c=
ertain expressions=A0involving=A0function pointers=A0aren&#39;t=A0useful/sa=
fe to allow=A0by default. Assuming that premise is correct, I&#39;m not yet=
 sure how to control that feature Hopefully that&#39;ll be clearer from oth=
er peoples ideas in the ensuing discussion I hope to start.</div>
<div><br></div><div>I don&#39;t realistically expect to=A0be able to presen=
t=A0any believable=A0 data=A0as to how much code=A0might reasonably=A0break=
 from changes in this area.=A0Hopefully=A0the potential breakage=A0level (o=
r not)=A0will become apparent=A0as people discus this idea further.</div>
<div>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1p=
x;border-left-style:solid">

Being able to sort (heterogenous/polymorphic) unordered containers on funct=
ion addresses before iterating (i.e. invoking each element) can measurably =
reduce instruction cache misses and is therefore a relevant tool for optimi=
zation. So this capability is required. If it&#39;s just the operator that =
causes trouble then the OP also has to propose some alternate way of perfor=
ming this operation as otherwise we would lose important functionality.<spa=
n><font color=3D"#888888"><br>

<br>
Miro</font></span><div><br></div></blockquote><div>Yes I imagined there mus=
t be some kind of use like this when I posted. But even now I still can&#39=
;t fully imagine exactly what such code would look like and how portable=A0=
one should=A0expect such code to be by default.</div>
<div><br></div><div>Miro, or anyone, can you submit a small piece of such c=
ode that you think should be supported? Then we could see if such code is a=
ctually portable, mainstream, or whatever and it would be easier to see wha=
t to make of it then.</div>
<div><div><br></div></div></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 />

--001a11332d167e4a5404f4c2d716--

.

--089e0149ce3c25e78404f4c369a0
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Mar 17, 2014 at 1:43 PM, David Krauss
<snip>

>
> GCC -Wextra gives me this:
>
> comp.cpp:4:10: warning: ordered comparison of pointer with integer zero
> [-Wextra]
>
> This should be as much solution to this problem as the world needs.
>
>  I think I tried -Wall with clang, I didn't try extra, else I might have
let sleeping dogs lie.

It would seem to me this warning could be improved such that a version of
it could/should be on by default.

It might be that comparing a function pointer to a constant might trigger a
warning by default, for example, rather than require -Wall or -Wextra.

I'm sure some improvement at least in that direction is possible.

But my gut feel is comparing function pointers isn't something that should
just happen so easily still. I'd rather not allow < operators to just work.
I don't think code should be entitled to make these kinds of assumptions on
function pointers so trivially and if they do, there perhaps should be more
explicit machinery to do that.

If it's inherently not portable making it inherently easy seems to be a bad
idea.

Restricting the operators that can be applied to function pointers would
seem to open up other possibilities too which might be another reason to
limit things here.

--

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

--089e0149ce3c25e78404f4c369a0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote">On Mon, Mar 17, 2014 at 1:43 PM=
, David Krauss </div><div class=3D"gmail_quote">&lt;snip&gt;</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex=
;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style=
:solid">
<div><div><div><br></div><div>GCC -Wextra gives me this:</div><div><br></di=
v><div><div style=3D"margin:0px;color:rgb(245,245,245);font-family:Monaco;f=
ont-size:8px;background-color:rgb(0,0,0)">comp.cpp:4:10: warning: ordered c=
omparison of pointer with integer zero [-Wextra]</div>
<div><br></div><div>This should be as much solution to this problem as the =
world needs.</div><div><br></div></div></div></div><div><div class=3D"h5">

<p></p>

</div></div></blockquote><div class=3D"gmail_extra">I think I tried -Wall w=
ith clang,=A0I didn&#39;t try=A0extra, else I might have let sleeping dogs =
lie.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I=
t would seem to me this warning could be improved such that a version of it=
 could/should be on by default.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It might be=
 that comparing a function pointer to a constant might trigger a warning by=
 default, for example, rather than require -Wall or -Wextra.</div><div clas=
s=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">I&#39;m sure some improvement at least=
 in that direction is possible.</div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">But my gut feel is comparing function pointers is=
n&#39;t something that should just happen so easily still. I&#39;d rather n=
ot allow=A0&lt; operators to just=A0work. I don&#39;t think code should be =
entitled to make these kinds of assumptions on function pointers so trivial=
ly=A0and if they do, there perhaps should be more explicit machinery to do =
that.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_extra">If it&#39;s inherently not portable making it inherently e=
asy seems to be a bad idea.</div><div class=3D"gmail_extra"><br></div></div=
><div class=3D"gmail_extra">
Restricting=A0the operators that can be applied to function=A0pointers woul=
d seem to open up other possibilities too which might be another reason to =
limit things=A0here.</div><div class=3D"gmail_extra"><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 />

--089e0149ce3c25e78404f4c369a0--

.

On 2014-03-16 17:53, gmisocpp@gmail.com wrote:
> I recently made a mistake in a program where if had some code that looked
> vaguely like this:
>
> int difference_ =3D 0;
> if ( difference > 0 )
>   printf("I feel a disturbance in the force.");
>
> It compiled fine, but didn't do as expected. It always printed the messag=
e.
> Clearly disturbing.
> I couldn't work out what was wrong from just looking at the code and thei=
r
> was no compiler warning, even with all warning on (I assume, unless I hav=
e
> a configuration error).
>
> It turned out the problem was simply difference is an existing function a=
nd
> I was testing the function pointer or something and not my local variable
> difference_.
> So it was like I had written
> if ( printf > 0)
>   do_something_dubious();

If you turn on e.g. GCC's -Wzero-as-null-pointer-constant (assuming you=20
are able to use 'nullptr' and/or change your code to use a symbol which=20
is either nullptr or 0 depending on compiler support), you would at=20
least get a warning here. Or surely one of the conversion-like warnings=20
would warn if you replace '0' with a variable having the value 0, or if=20
the literal value wasn't '0'. (Or as David points out, apparently=20
-Wextra already warns on this.)

As mentioned elsewhere, pointer comparisons in general are useful.=20
What's really biting you here is that '0' is implicitly converted to a=20
pointer, and there is an existing warning for that. (You might also=20
propose to warn about or disallow using an ordering comparison between a=20
pointer and nullptr/0, which is pretty much always silly=C2=B9. Though if y=
ou=20
compare ptr < 0 or ptr >=3D 0, you probably already get a warning, so=20
really this would mainly apply to ptr > 0.)

(=C2=B9 ...because you probably don't want ordering, but rather !=3D, or ju=
st=20
conversion to bool, especially if pointers are considered unsigned s.t.=20
ptr > 0 and ptr !=3D 0 are the same.)

--=20
Matthew

--=20

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

.

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

Hi

> > So it was like I had written=20
> > if ( printf > 0)=20
> >   do_something_dubious();=20
>
> If you turn on e.g. GCC's -Wzero-as-null-pointer-constant (assuming you=
=20
> are able to use 'nullptr' and/or change your code to use a symbol which=
=20
> is either nullptr or 0 depending on compiler support), you would at=20
> least get a warning here. Or surely one of the conversion-like warnings=
=20
> would warn if you replace '0' with a variable having the value 0, or if=
=20
> the literal value wasn't '0'. (Or as David points out, apparently=20
> -Wextra already warns on this.)=20
>
> As mentioned elsewhere, pointer comparisons in general are useful.=20
> What's really biting you here is that '0' is implicitly converted to a=20
> pointer, and there is an existing warning for that. (You might also=20
> propose to warn about or disallow using an ordering comparison between a=
=20
> pointer and nullptr/0, which is pretty much always silly=C2=B9. Though if=
 you=20
> compare ptr < 0 or ptr >=3D 0, you probably already get a warning, so=20
> really this would mainly apply to ptr > 0.)=20
>
> (=C2=B9 ...because you probably don't want ordering, but rather !=3D, or =
just=20
> conversion to bool, especially if pointers are considered unsigned s.t.=
=20
> ptr > 0 and ptr !=3D 0 are the same.)=20
>
> --=20
> Matthew=20
>

You are right. It is that 0 is converting to a pointer for use in=20
relational operators that bites.

With this test program:

#include <cstdio>
int main()
{
    printf("Hello world\n");
    if (printf > 0)
        printf("Hello surprisingly!\n");
    auto pf =3D printf;
    pf("Hello indirectly\n");
    if (pf > 0)
        pf("Hello surprisingly too!\n");
    if (pf > nullptr)
        pf("Hello again!\n");
}

Using clang 3.5, built fresh from source to compile:
clang++ -Wall -Wextra -std=3Dc++1y fp.cpp

I find clang is silent. Surprising. MSVC is too.

Using g++ 4.8.2, as you say, yields:

g++ -Wall -Wextra -std=3Dc++1y fp.cpp
fp.cpp: In function 'int main()':
fp.cpp:6:18: warning: ordered comparison of pointer with integer zero=20
[-Wextra]
     if (printf > 0)
                  ^
fp.cpp:10:14: warning: ordered comparison of pointer with integer zero=20
[-Wextra]
     if (pf > 0)
              ^
fp.cpp:12:14: warning: ordered comparison of pointer with integer zero=20
[-Wextra]
     if (pf > nullptr)
              ^
g++ is much more vocal and more correct according to my preferences (not=20
making any claims about the Standard.)

However I don't think either is perfect for my tastes.

What I would like to see is that constant 0 not be convertible to a pointer=
=20
at least when used with relational operators.
I can accept that  !=3D and =3D=3D must work for compatibility sake, but I =
think=20
constant 0 conversion to pointer with >=3D <=3D etc. is something to disall=
ow=20
or deprecate. I'd hope that what code breaks from that change would be=20
acceptably low and noisy to allow for that to be acceptable.

I'd definitely have expected clang to warn here somewhat like gcc=20
has, but what I'd like and expect to see here is that every compiler at=20
least warn *by default* and at lowest level warnings or  preferably error,=
=20
when a constant 0 to pointer conversion with relational operator expression=
=20
is found like the original example.

I'm somewhat surprised by gcc warning with nullptr here and might have=20
expected the warning to be different to the constant 0 case too.

Thanks

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

<div dir=3D"ltr">Hi<br><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;">&gt; So it was like I h=
ad written
<br>&gt; if ( printf &gt; 0)
<br>&gt; &nbsp; do_something_dubious();
<br>
<br>If you turn on e.g. GCC's -Wzero-as-null-pointer-<wbr>constant (assumin=
g you=20
<br>are able to use 'nullptr' and/or change your code to use a symbol which=
=20
<br>is either nullptr or 0 depending on compiler support), you would at=20
<br>least get a warning here. Or surely one of the conversion-like warnings=
=20
<br>would warn if you replace '0' with a variable having the value 0, or if=
=20
<br>the literal value wasn't '0'. (Or as David points out, apparently=20
<br>-Wextra already warns on this.)
<br>
<br>As mentioned elsewhere, pointer comparisons in general are useful.=20
<br>What's really biting you here is that '0' is implicitly converted to a=
=20
<br>pointer, and there is an existing warning for that. (You might also=20
<br>propose to warn about or disallow using an ordering comparison between =
a=20
<br>pointer and nullptr/0, which is pretty much always silly=C2=B9. Though =
if you=20
<br>compare ptr &lt; 0 or ptr &gt;=3D 0, you probably already get a warning=
, so=20
<br>really this would mainly apply to ptr &gt; 0.)
<br>
<br>(=C2=B9 ...because you probably don't want ordering, but rather !=3D, o=
r just=20
<br>conversion to bool, especially if pointers are considered unsigned s.t.=
=20
<br>ptr &gt; 0 and ptr !=3D 0 are the same.)
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div>You are right. It is that 0 is convert=
ing to a pointer for use in relational operators that bites.</div><div><br>=
</div><div>With this test program:</div><div><br></div><div>#include &lt;cs=
tdio&gt;</div><div>int main()<br>{<br>&nbsp;&nbsp;&nbsp; printf("Hello worl=
d\n");<br>&nbsp;&nbsp;&nbsp; if (printf &gt; 0)<br>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; printf("Hello surprisingly!\n");<br>&nbsp;&nbsp;&nbsp; a=
uto pf =3D printf;<br>&nbsp;&nbsp;&nbsp; pf("Hello indirectly\n");<br>&nbsp=
;&nbsp;&nbsp; if (pf &gt; 0)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
pf("Hello surprisingly too!\n");<br>&nbsp;&nbsp;&nbsp; if (pf &gt; nullptr)=
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pf("Hello again!\n");<br>}</=
div><div><br></div><div>Using clang 3.5, built&nbsp;fresh from source to co=
mpile:</div><div>clang++&nbsp;-Wall -Wextra -std=3Dc++1y fp.cpp</div><div><=
br></div><div>I find clang is silent. Surprising. MSVC is too.</div><div><b=
r></div><div>Using g++ 4.8.2, as you say, yields:</div><div><br></div><div>=
g++ -Wall -Wextra -std=3Dc++1y fp.cpp<br>fp.cpp: In function 'int main()':<=
br>fp.cpp:6:18: warning: ordered comparison of pointer with integer zero [-=
Wextra]<br>&nbsp;&nbsp;&nbsp;&nbsp; if (printf &gt; 0)<br>&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; ^<br>fp.cpp:10:14: warning: ordered comparison of pointer with i=
nteger zero [-Wextra]<br>&nbsp;&nbsp;&nbsp;&nbsp; if (pf &gt; 0)<br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^<b=
r>fp.cpp:12:14: warning: ordered comparison of pointer with integer zero [-=
Wextra]<br>&nbsp;&nbsp;&nbsp;&nbsp; if (pf &gt; nullptr)<br>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^</div><div=
>g++ is much more vocal and more correct according to my preferences (not m=
aking any claims about the Standard.)</div><div><br></div><div>However I do=
n't think either is perfect for my tastes.</div><div><br></div><div>What I =
would like to see is that&nbsp;constant 0&nbsp;not be convertible to a poin=
ter at least when used&nbsp;with relational operators.</div><div>I&nbsp;can=
&nbsp;accept that&nbsp; !=3D and =3D=3D&nbsp;must work for compatibility sa=
ke, but I think constant 0 conversion to pointer&nbsp;with&nbsp;&gt;=3D &lt=
;=3D etc.&nbsp;is something to disallow or deprecate. I'd hope that&nbsp;wh=
at code breaks from that change would be acceptably low and noisy to allow =
for that to be acceptable.</div><div><br></div><div>I'd definitely have&nbs=
p;expected clang to warn here somewhat like gcc has,&nbsp;but&nbsp;what I'd=
 like and&nbsp;expect to see&nbsp;here is that every compiler&nbsp;at least=
 warn&nbsp;*by default* and at lowest level warnings&nbsp;or&nbsp;&nbsp;pre=
ferably&nbsp;error, when a constant 0 to pointer conversion with relational=
 operator expression is found like the original example.</div><div><br></di=
v><div>I'm somewhat surprised by gcc warning with nullptr here and&nbsp;mig=
ht have expected the warning to be different to the constant 0 case too.</d=
iv><div><br></div><div>Thanks</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_45_21580278.1395089184041--

.

On 2014-03-17 16:46, gmisocpp@gmail.com wrote:
> You are right. It is that 0 is converting to a pointer for use in
> relational operators that bites.
> [...]
> What I would like to see is that constant 0 not be convertible to a pointer
> at least when used with relational operators.

I'm not sure if that's possible as such. What I think could be valuable,
though, and might have the same (or at least similar) effect, would be
to make ill-formed an ordering comparison (i.e. operators <, >, <=, >=)
between a T* and nullptr_t.

This would still allow e.g. this:

   auto* a = expr;
   auto* b = decltype(a){0};
   if (a < b) ...

....but I suspect that if anyone has written code like that, they really
intend to order pointers. And anyway this is no longer "constant 0" as
you indicated, so I believe we are on the same page.

p.s. Comparison between a pointer and a numeric type is already illegal,
so we're already okay in the case of e.g. 'printf < int{0}'.

> I'm somewhat surprised by gcc warning with nullptr here and might have
> expected the warning to be different to the constant 0 case too.

I'm not; in C++11, where '0' is interpreted as a pointer, AFAIK the
effect is always the same as if you had written 'nullptr' instead. (If
anything I'm surprised that the error message says "integer zero" rather
than e.g. "nullptr". Especially in the last case :-) - so with you there
- but I would think it reasonable if in both cases the compiler named
the RHS as "nullptr".)

--
Matthew

--

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

.

------=_Part_23_21755976.1395262722598
Content-Type: text/plain; charset=UTF-8

HI

On Thursday, March 20, 2014 6:12:44 AM UTC+13, Matthew Woehlke wrote:
>
> On 2014-03-17 16:46, gmis...@gmail.com <javascript:> wrote:
> > You are right. It is that 0 is converting to a pointer for use in
> > relational operators that bites.
> > [...]
> > What I would like to see is that constant 0 not be convertible to a
> pointer
> > at least when used with relational operators.
>
> I'm not sure if that's possible as such.

Why? g++ warns on it in my example, so why can't that be extended
further if we are so inclined?


> What I think could be valuable,
> though, and might have the same (or at least similar) effect, would be
> to make ill-formed an ordering comparison (i.e. operators <, >, <=, >=)
> between a T* and nullptr_t.
>
That sounds a lot like what I'm asking for so I'm not sure what
you were referring to above as "not sure that's possible" now.

>
> This would still allow e.g. this:
>
>    auto* a = expr;
>    auto* b = decltype(a){0};
>    if (a < b) ...
>
> ...but I suspect that if anyone has written code like that, they really
> intend to order pointers. And anyway this is no longer "constant 0" as
> you indicated, so I believe we are on the same page.
>
> p.s. Comparison between a pointer and a numeric type is already illegal,
> so we're already okay in the case of e.g. 'printf < int{0}'.
>

I want to know why we can't harden compilers to have issues with this
statement:
     if (printf > 0)
And require it to be specified in different terms, i.e. not of integer
0, if that's really what they want, e.g.:
   if (printf > (appropriate type cast) nullptr)

>
> > I'm somewhat surprised by gcc warning with nullptr here and might have
> > expected the warning to be different to the constant 0 case too.
>
> I'm not; in C++11, where '0' is interpreted as a pointer, AFAIK the
> effect is always the same as if you had written 'nullptr' instead. (If
> anything I'm surprised that the error message says "integer zero" rather
> than e.g. "nullptr". Especially in the last case :-) - so with you there
> - but I would think it reasonable if in both cases the compiler named
> the RHS as "nullptr".)
>
> --
> Matthew
>

Yes the referring to nullptr as integer 0 is surprising, but that's the
whole problem with 0 and nullptr equating so easily and in relational
operators specifically I want to lessen that ease.
I can't as yet see what would prevent this though I do see it as less of a
deal than I thought it was as I initially was thinking the scope of things
was larger.
But I still think it can be improved from where we are at now.
clang doesn't warn on this usage at all and I think it should. I think
gcc's warning should be improved. Ideally I'd like to see it warn on the
lowest levels or error with such expressions.

I haven't read anything yet that makes it clear to me why that isn't
possible.

I think the code that uses the constant 0 in this way that would break
would be minimal and break noisily until a suitable cast was applied and
the compiler could tell you exactly what that cast should be in all
likely-hood.

I'm looking for a clear case why that statement isn't true and I haven't
seen it yet.

Thanks

--

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

<div dir=3D"ltr">HI<br><br>On Thursday, March 20, 2014 6:12:44 AM UTC+13, M=
atthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;">On 2014-03-17 16:46, <a o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"vgVLvlwllRcJ">gmis...@gmail.com</a> wrote:
<br>&gt; You are right. It is that 0 is converting to a pointer for use in
<br>&gt; relational operators that bites.
<br>&gt; [...]
<br>&gt; What I would like to see is that constant 0 not be convertible to =
a pointer
<br>&gt; at least when used with relational operators.
<br>
<br>I'm not sure if that's possible as such.</blockquote><div>Why? g++ warn=
s on it in my example, so why can't that be extended further&nbsp;if we are=
 so inclined?</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"> What I th=
ink could be valuable,=20
<br>though, and might have the same (or at least similar) effect, would be=
=20
<br>to make ill-formed an ordering comparison (i.e. operators &lt;, &gt;, &=
lt;=3D, &gt;=3D)=20
<br>between a T* and nullptr_t.
<br></blockquote><div>That sounds a lot like what I'm asking for&nbsp;so I'=
m not sure what you&nbsp;were&nbsp;referring to above as&nbsp;"not sure tha=
t's possible" now.</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204)=
; border-left-width: 1px; border-left-style: solid;">
<br>This would still allow e.g. this:
<br>
<br>&nbsp; &nbsp;auto* a =3D expr;
<br>&nbsp; &nbsp;auto* b =3D decltype(a){0};
<br>&nbsp; &nbsp;if (a &lt; b) ...
<br>
<br>...but I suspect that if anyone has written code like that, they really=
=20
<br>intend to order pointers. And anyway this is no longer "constant 0" as=
=20
<br>you indicated, so I believe we are on the same page.
<br>
<br>p.s. Comparison between a pointer and a numeric type is already illegal=
,=20
<br>so we're already okay in the case of e.g. 'printf &lt; int{0}'.
<br></blockquote><div><br></div><div>I want to know why we can't harden com=
pilers to have issues with this statement:</div><div>&nbsp;&nbsp;&nbsp;&nbs=
p; if (printf &gt; 0)<br>And require it to be specified in&nbsp;different t=
erms, i.e. not of integer 0,&nbsp;if that's really what they want, e.g.:&nb=
sp;</div><div>&nbsp;&nbsp; if (printf &gt; (appropriate type cast) nullptr)=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;">
<br>&gt; I'm somewhat surprised by gcc warning with nullptr here and might =
have
<br>&gt; expected the warning to be different to the constant 0 case too.
<br>
<br>I'm not; in C++11, where '0' is interpreted as a pointer, AFAIK the=20
<br>effect is always the same as if you had written 'nullptr' instead. (If=
=20
<br>anything I'm surprised that the error message says "integer zero" rathe=
r=20
<br>than e.g. "nullptr". Especially in the last case :-) - so with you ther=
e=20
<br>- but I would think it reasonable if in both cases the compiler named=
=20
<br>the RHS as "nullptr".)
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div>Yes the&nbsp;referring to nullptr as i=
nteger 0 is surprising, but&nbsp;that's the whole problem with 0 and nullpt=
r equating so easily and in relational operators specifically I want to les=
sen that ease.&nbsp;</div><div>I can't as yet see what would prevent this t=
hough I do see it as less of a deal than I thought it was as I initially wa=
s thinking the scope of things was larger.</div><div>But I still think it c=
an be improved from where we are at now.</div><div>clang doesn't warn on th=
is usage at all and I think it should. I think gcc's warning should be impr=
oved. Ideally I'd like to see it warn on the lowest levels or error with su=
ch expressions.</div><div><br></div><div>I haven't read anything yet that m=
akes it clear to me why that isn't possible.</div><div><br></div><div>I thi=
nk the code that uses the constant 0 in this way&nbsp;that would break woul=
d be minimal and break noisily until a suitable cast was applied and the co=
mpiler could tell you exactly what that cast should be in all likely-hood.<=
/div><div><br></div><div>I'm looking for a clear case why that statement is=
n't true and I haven't seen it yet.</div><div><br></div><div>Thanks</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_23_21755976.1395262722598--

.

On 2014-03-19 16:58, gmisocpp@gmail.com wrote:
> HI
>
> On Thursday, March 20, 2014 6:12:44 AM UTC+13, Matthew Woehlke wrote:
>>
>> On 2014-03-17 16:46, gmis...@gmail.com <javascript:> wrote:
>>> You are right. It is that 0 is converting to a pointer for use in
>>> relational operators that bites.
>>> [...]
>>> What I would like to see is that constant 0 not be convertible to a
>>> pointer at least when used with relational operators.
>>
>> I'm not sure if that's possible as such.
>
> Why? g++ warns on it in my example, so why can't that be extended
> further if we are so inclined?

....but it's "really" warning about comparison with 'nullptr'. I'm=20
unconvinced that the implicit conversion of '0' to 'nullptr' can or=20
should be prevented, even in this case. But...

>> What I think could be valuable,
>> though, and might have the same (or at least similar) effect, would be
>> to make ill-formed an ordering comparison (i.e. operators <, >, <=3D, >=
=3D)
>> between a T* and nullptr_t.
>
> That sounds a lot like what I'm asking for so I'm not sure what
> you were referring to above as "not sure that's possible" now.

....I believe we agree that the comparison should be prevented for=20
nullptr, whether or not an implicit conversion from an integer 0=20
constant occurred.

(Maybe we're just experiencing terminology confusion? I may be=20
misinterpreting where you wrote "constant 0" above, which I took to mean=20
e.g. the 'literal string "0"' i.e. before implicit conversion to nullptr.)

> I want to know why we can't harden compilers to have issues with this
> statement:
>       if (printf > 0)

See previous comments. Right now, "0" here is implicitly converted to=20
nullptr. So if we disallow operator< between T* and nullptr_t, we will=20
disallow the above. (The only "gotcha" is to make sure that the "0"=20
really does convert to "nullptr" and not "(T*)(0)"... and, apparently,=20
to resolve that currently there is an overload ambiguity here, although=20
given that we want it to be an error, resolving the ambiguity is rather=20
superfluous.)

All I'm saying is to not try to interfere with the conversion of "0" to=20
nullptr and/or try to prevent the comparison before that conversion=20
occurs. (Maybe that was also your intent as well, and I am just confused?)

I don't see a problem disallowing ordering comparisons between a pointer=20
type and nullptr_t, and am in favor of doing so.

> And require it to be specified in different terms, i.e. not of integer
> 0, if that's really what they want, e.g.:
>     if (printf > (appropriate type cast) nullptr)

Right. Once the nullptr (whether it's spelled "nullptr" or "0") is=20
coerced into an appropriate pointer type, the comparison would be=20
allowed. (Needed for the general ordering case, as we already know.)

> Yes the referring to nullptr as integer 0 is surprising

I suspect the warning predates 'nullptr', and that when 'nullptr' was=20
introduced, the conversion of "0" to "nullptr" is happening first, and=20
the warning was changed to handle comparison between T* and nullptr_t,=20
but the text was not updated accordingly.

> but that's the whole problem with 0 and nullptr equating so easily
> and in relational operators specifically I want to lessen that ease.

Changing that implicit conversion in general would break compatibility.=20
And I'd be uncomfortable treating 'a < 0' differently from 'a <=20
nullptr'... besides that I'm inclined to disallow both of those.

> clang doesn't warn on this usage at all and I think it should.

Definitely. I'd file a bug report if you haven't already. (But that's OT=20
for here.)

> I think gcc's warning should be improved. Ideally I'd like to see it
> warn on the lowest levels or error with such expressions.

I don't think it's allowed to error by default=C2=B9 until/unless we change=
=20
the standard. This particular warning should probably have its own=20
flag=C2=B2, though, and be on by default. Again, I encourage you to file a=
=20
bug report :-).

(=C2=B9 If it errored by default, that would make the compiler=20
non-conforming, which for obvious reasons I don't expect the devs to=20
accept. Though I'm not sure, e.g. see the stuff that -fpermissive=20
allows; maybe this could be a case for that.)

(=C2=B2 The "own flag" is mainly/only because I suspect being on by default=
=20
mandates an independent flag so that it can be turned off.)

--=20
Matthew

--=20

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

.

--bcaec52d4acf28b62804f4fcf27f
Content-Type: text/plain; charset=ISO-8859-1

On 19 March 2014 16:59, Matthew Woehlke <mw_triad@users.sourceforge.net>wrote:

>
> I don't see a problem disallowing ordering comparisons between a pointer
> type and nullptr_t, and am in favor of doing so.


C++1y maps using predicates like std::less<void> allow key comparisons
between different types.  I think that would break.

Just pointing it out; I'm neutral to weakly against this proposal, as I
don't think the problem happens enough in practice to make a change to the
standard.
--
 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/.

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

<div dir=3D"ltr">On 19 March 2014 16:59, Matthew Woehlke <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_=
triad@users.sourceforge.net</a>&gt;</span> wrote:<br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D""><br></div>
I don&#39;t see a problem disallowing ordering comparisons between a pointe=
r type and nullptr_t, and am in favor of doing so.</blockquote><div><br></d=
iv><div>C++1y maps using predicates like std::less&lt;void&gt; allow key co=
mparisons between different types. =A0I think that would break.</div>

<div><br></div><div>Just pointing it out; I&#39;m neutral to weakly against=
 this proposal, as I don&#39;t think the problem happens enough in practice=
 to make a change to the standard.</div></div>-- <br>=A0Nevin &quot;:-)&quo=
t; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</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 />

--bcaec52d4acf28b62804f4fcf27f--

.

On 03/19/2014 11:11 PM, Nevin Liber wrote:
> On 19 March 2014 16:59, Matthew Woehlke <mw_triad@users.sourceforge.net <mailto:mw_triad@users.sourceforge.net>> wrote:
>
>
>     I don't see a problem disallowing ordering comparisons between a pointer type and nullptr_t, and am in favor of doing so.
>
>
> C++1y maps using predicates like std::less<void> allow key comparisons between different types.  I think that would break.

Please elaborate.

A relational comparison of a value of pointer type with a value of nullptr_t is
always undefined behavior (because those two pointers do not point into the same
array), so if there is any syntax error being introduced for that case, that's
actually a good thing.

Jens

--

---
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 2014-03-19 18:11, Nevin Liber wrote:
> On 19 March 2014 16:59, Matthew Woehlke wrote:
>> I don't see a problem disallowing ordering comparisons between a pointer
>> type and nullptr_t, and am in favor of doing so.
>
> C++1y maps using predicates like std::less<void> allow key comparisons
> between different types.  I think that would break.

When is a container passing a nullptr (or literal 0) into std::less?

--
Matthew

--

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

.

--001a1133c9aac6080504f4fd8c3d
Content-Type: text/plain; charset=ISO-8859-1

On 19 March 2014 17:24, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> A relational comparison of a value of pointer type with a value of
> nullptr_t is
> always undefined behavior (because those two pointers do not point into
> the same
> array),


Ah, I forgot the "weasel words" at the end of [comparisons] that are there
for less<T*> (and the other comparators) aren't there for less<void>.

Still, does that mean:

char* p = nullptr;
assert(!(nullptr < p));

invokes UB?

Although it is UB from the standards point of view, it tends to be defined
on most platforms anyway, as I have yet to see an implementation of
std::less<T*> which does not just call operator<.
--
 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/.

--001a1133c9aac6080504f4fd8c3d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 19 March 2014 17:24, Jens Maurer <span dir=3D"ltr">&lt;=
<a href=3D"mailto:Jens.Maurer@gmx.net" target=3D"_blank">Jens.Maurer@gmx.ne=
t</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex">

A relational comparison of a value of pointer type with a value of nullptr_=
t is<br>
always undefined behavior (because those two pointers do not point into the=
 same<br>
array),</blockquote><div><br></div><div>Ah, I forgot the &quot;weasel words=
&quot; at the end of [comparisons] that are there for less&lt;T*&gt; (and t=
he other comparators) aren&#39;t there for less&lt;void&gt;.</div><div>

<br></div><div>Still, does that mean:</div><div><br></div><div>char* p =3D =
nullptr;</div><div>assert(!(nullptr &lt; p));</div><div><br></div><div>invo=
kes UB?</div><div><br></div><div>Although it is UB from the standards point=
 of view, it tends to be defined on most platforms anyway, as I have yet to=
 see an implementation of std::less&lt;T*&gt; which does not just call oper=
ator&lt;.</div>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</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 />

--001a1133c9aac6080504f4fd8c3d--

.

Em qua 19 mar 2014, =E0s 23:24:21, Jens Maurer escreveu:
> On 03/19/2014 11:11 PM, Nevin Liber wrote:
> > On 19 March 2014 16:59, Matthew Woehlke <mw_triad@users.sourceforge.net=
=20
<mailto:mw_triad@users.sourceforge.net>> wrote:
> >     I don't see a problem disallowing ordering comparisons between a
> >     pointer type and nullptr_t, and am in favor of doing so.>=20
> > C++1y maps using predicates like std::less<void> allow key comparisons
> > between different types.  I think that would break.
> Please elaborate.
>=20
> A relational comparison of a value of pointer type with a value of nullpt=
r_t
> is always undefined behavior (because those two pointers do not point int=
o
> the same array), so if there is any syntax error being introduced for tha=
t
> case, that's actually a good thing.

It says "unspecified", not UB:

expr.rel, 2:
If two pointers p and q of the same type point to different objects that ar=
e=20
not members of the same object or elements of the same array or to differen=
t=20
functions, or if only one of them is null, the results of p<q, p>q, p<=3Dq,=
 and=20
p>=3Dq are unspecified.

It's useful to have the comparison to null be unspecified because the=20
comparison can be executed some compilers/machines/ABI may choose to use=20
signed comparisons for pointers. That would mean certain pointers compare t=
o=20
be less than null and some others compare to be greater than null. Not to=
=20
mention, of course, that the null pointer representation doesn't need to be=
 a=20
bitwise zero -- the portable ABI has a -1 for a null pointer-to-member=20
representation.

But the comparison still has a behaviour and the program continues running.

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

.

--089e013a0dbc7ea94f04f4fda4ca
Content-Type: text/plain; charset=ISO-8859-1

On 19 March 2014 17:41, Matthew Woehlke <mw_triad@users.sourceforge.net>wrote:

>
> When is a container passing a nullptr (or literal 0) into std::less?


You could have a container of, say, map<char*, int, less<>> and want to do
a m.find(nullptr).
--
 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/.

--089e013a0dbc7ea94f04f4fda4ca
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 19 March 2014 17:41, Matthew Woehlke <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_=
triad@users.sourceforge.net</a>&gt;</span> wrote:<br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br></div>
When is a container passing a nullptr (or literal 0) into std::less?</block=
quote><div><br></div><div>You could have a container of, say, map&lt;char*,=
 int, less&lt;&gt;&gt; and want to do a m.find(nullptr).</div></div>-- <br>


=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@evilov=
erlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 <a href=3D"=
tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 69=
1-1404</a>
</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 />

--089e013a0dbc7ea94f04f4fda4ca--

.

On 2014-03-19 18:54, Nevin Liber wrote:
> Still, does that mean:
>
> char* p = nullptr;
> assert(!(nullptr < p));
>
> invokes UB?

The proposal would make this a compile error. You would need to
explicitly cast the 'nullptr' to char*. (At which point you will get the
same behavior as before; the behavior of operator<(T*, T*) is not changed.)

--
Matthew

--

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

.

On 2014-03-19 19:01, Nevin Liber wrote:
> On 19 March 2014 17:41, Matthew Woehlke wrote:
>> When is a container passing a nullptr (or literal 0) into std::less?
>
> You could have a container of, say, map<char*, int, less<>> and want to do
> a m.find(nullptr).

Is there an overload of std::map<T*>::find which takes a nullptr_t? If
not, then that case is not affected because you aren't comparing against
nullptr_t, you are comparing against a T* which happens to have a value
of nullptr.

Last I knew, once nullptr has a concrete pointer type, it is never
implicitly converted back to nullptr_t.

--
Matthew

--

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

.

--089e01183daacc108c04f4fdecee
Content-Type: text/plain; charset=ISO-8859-1

On 19 March 2014 18:16, Matthew Woehlke <mw_triad@users.sourceforge.net>wrote:

> On 2014-03-19 19:01, Nevin Liber wrote:
>
>  On 19 March 2014 17:41, Matthew Woehlke wrote:
>>
>>> When is a container passing a nullptr (or literal 0) into std::less?
>>>
>>
>> You could have a container of, say, map<char*, int, less<>> and want to do
>> a m.find(nullptr).
>>
>
> Is there an overload of std::map<T*>::find which takes a nullptr_t?


In C++1y, there is one for map<T*, int, less<>> (the signature matters).
 There is template <class K> iterator find(const K& x);


> If not, then that case is not affected because you aren't comparing
> against nullptr_t, you are comparing against a T* which happens to have a
> value of nullptr.
>

It would also be weird that map<shared_ptr<T>, int, less<>> would work but
map<T*, int, less<>> would not.  Ordered comparisons between shared_ptr<T>
and nullptr_t were deliberately added.

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

--089e01183daacc108c04f4fdecee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 19 March 2014 18:16, Matthew Woehlke <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_=
triad@users.sourceforge.net</a>&gt;</span> wrote:<br><div class=3D"gmail_ex=
tra"><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;p=
adding-left:1ex">On 2014-03-19 19:01, Nevin Liber wrote:<div class=3D""><br=
>

<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;p=
adding-left:1ex">
On 19 March 2014 17:41, Matthew Woehlke wrote:<br>
<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;p=
adding-left:1ex">
When is a container passing a nullptr (or literal 0) into std::less?<br>
</blockquote>
<br>
You could have a container of, say, map&lt;char*, int, less&lt;&gt;&gt; and=
 want to do<br>
a m.find(nullptr).<br>
</blockquote>
<br></div>
Is there an overload of std::map&lt;T*&gt;::find which takes a nullptr_t?</=
blockquote><div><br></div><div>In C++1y, there is one for map&lt;T*, int, l=
ess&lt;&gt;&gt; (the signature matters). =A0There is=A0<span style=3D"font-=
family:Helvetica;font-size:9px">template &lt;class K&gt; iterator find(cons=
t K&amp; x);</span></div>

<div>=A0</div><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"> If not, then that case is not affected beca=
use you aren&#39;t comparing against nullptr_t, you are comparing against a=
 T* which happens to have a value of nullptr.<br>

</blockquote><div><br></div><div>It would also be weird that map&lt;shared_=
ptr&lt;T&gt;, int, less&lt;&gt;&gt; would work but map&lt;T*, int, less&lt;=
&gt;&gt; would not. =A0Ordered comparisons between shared_ptr&lt;T&gt; and =
nullptr_t were deliberately added.</div>

</div><div><br></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a=
 href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlor=
d.com</a>&gt;=A0 (847) 691-1404
</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 />

--089e01183daacc108c04f4fdecee--

.

On 2014-03-19 19:00, Thiago Macieira wrote:
> expr.rel, 2:
> If two pointers p and q of the same type point to different objects that are
> not members of the same object or elements of the same array or to different
> functions, or if only one of them is null, the results of p<q, p>q, p<=q, and
> p>=q are unspecified.

....and to be clear, I don't believe anyone here is suggesting any change
that would affect this. nullptr_t "is not" a pointer type. Once it has
been explicitly assigned to a concrete pointer, e.g. because it was
passed via a variable or explicitly, casted, the ordering operation
would proceed as always.

IOW, this:

   int* a = foo();
   if (a < nullptr)
     /*...*/;

....shall be a *compile error*, because operator<(int*, nullptr_t) is
disallowed. But this:

   int* a = foo(), b = nullptr;
   if (a < b)
     /*...*/;

....is not affected, because the type of both operands is int*, and we
aren't suggesting to change that case. Similarly, this:

   int* a = foo();
   if (a < int*{nullptr})
     /*...*/;

....is also not affected for the same reason.

--
Matthew

--

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

.

On 03/19/2014 11:54 PM, Nevin Liber wrote:
> On 19 March 2014 17:24, Jens Maurer <Jens.Maurer@gmx.net <mailto:Jens.Maurer@gmx.net>> wrote:
>
>     A relational comparison of a value of pointer type with a value of nullptr_t is
>     always undefined behavior (because those two pointers do not point into the same
>     array),
>
>
> Ah, I forgot the "weasel words" at the end of [comparisons] that are there for less<T*> (and the other comparators) aren't there for less<void>.
>
> Still, does that mean:
>
> char* p = nullptr;
> assert(!(nullptr < p));
>
> invokes UB?

Yes.

> Although it is UB from the standards point of view,

Which is what matters.   We want to keep supporting segmented
architectures.

Jens

--

---
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 03/20/2014 12:00 AM, Thiago Macieira wrote:
> Em qua 19 mar 2014, =C4=85s 23:24:21, Jens Maurer escreveu:
>> On 03/19/2014 11:11 PM, Nevin Liber wrote:
>>> On 19 March 2014 16:59, Matthew Woehlke <mw_triad@users.sourceforge.net=
=20
> <mailto:mw_triad@users.sourceforge.net>> wrote:
>>>     I don't see a problem disallowing ordering comparisons between a
>>>     pointer type and nullptr_t, and am in favor of doing so.>=20
>>> C++1y maps using predicates like std::less<void> allow key comparisons
>>> between different types.  I think that would break.
>> Please elaborate.
>>
>> A relational comparison of a value of pointer type with a value of nullp=
tr_t
>> is always undefined behavior (because those two pointers do not point in=
to
>> the same array), so if there is any syntax error being introduced for th=
at
>> case, that's actually a good thing.
>=20
> It says "unspecified", not UB:

Ah, right.  That still makes it useless for std::map comparisons.
(You need a stable ordering operation for that.)

Jens

--=20

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

.

On 03/20/2014 12:36 AM, Jens Maurer wrote:
> On 03/19/2014 11:54 PM, Nevin Liber wrote:
>> On 19 March 2014 17:24, Jens Maurer <Jens.Maurer@gmx.net <mailto:Jens.Maurer@gmx.net>> wrote:
>>
>>     A relational comparison of a value of pointer type with a value of nullptr_t is
>>     always undefined behavior (because those two pointers do not point into the same
>>     array),
>>
>>
>> Ah, I forgot the "weasel words" at the end of [comparisons] that are there for less<T*> (and the other comparators) aren't there for less<void>.
>>
>> Still, does that mean:
>>
>> char* p = nullptr;
>> assert(!(nullptr < p));
>>
>> invokes UB?
>
> Yes.

Correction: unspecified value

>> Although it is UB from the standards point of view,
>
> Which is what matters.   We want to keep supporting segmented
> architectures.
>
> Jens
>

--

---
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 03/20/2014 12:20 AM, Matthew Woehlke wrote:
> On 2014-03-19 19:00, Thiago Macieira wrote:
>> expr.rel, 2:
>> If two pointers p and q of the same type point to different objects that are
>> not members of the same object or elements of the same array or to different
>> functions, or if only one of them is null, the results of p<q, p>q, p<=q, and
>> p>=q are unspecified.
>
> ...and to be clear, I don't believe anyone here is suggesting any change
> that would affect this. nullptr_t "is not" a pointer type. Once it has
> been explicitly assigned to a concrete pointer, e.g. because it was
> passed via a variable or explicitly, casted, the ordering operation
> would proceed as always.
>
> IOW, this:
>
>    int* a = foo();
>    if (a < nullptr)
>      /*...*/;
>
> ...shall be a *compile error*, because operator<(int*, nullptr_t) is
> disallowed.

Just to be clear: The status quo in 5.9 converts "nullptr" to the
type of "a" and is then happy to perform the comparison.  We need
to disallow this conversion in case a nullptr_t is one of the operands
of a relational operator.

>  But this:
>
>    int* a = foo(), b = nullptr;
>    if (a < b)
>      /*...*/;
>
> ...is not affected, because the type of both operands is int*, and we
> aren't suggesting to change that case. Similarly, this:
>
>    int* a = foo();
>    if (a < int*{nullptr})
>      /*...*/;
>
> ...is also not affected for the same reason.

In neither case, you can know at compile-time which value you're comparing
with, so it cannot be ill-formed.

Jens

--

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

.

Em qui 20 mar 2014, =E0s 00:38:53, Jens Maurer escreveu:
> > It says "unspecified", not UB:
> Ah, right.  That still makes it useless for std::map comparisons.
> (You need a stable ordering operation for that.)

It's stable. It's just not specified what it is.

By the way, I was trying to compare two pointer-to-member and ICC, GCC and=
=20
Clang all complained that I wasn't allowed to, even if the standard says it=
=20
should be possible. Any opinions?
--=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_94_31835395.1395278612797
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi

On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wrote:

> On 2014-03-19 16:58, gmis...@gmail.com <javascript:> wrote:=20
> > HI=20
> >=20
> > On Thursday, March 20, 2014 6:12:44 AM UTC+13, Matthew Woehlke wrote:=
=20
> >>=20
> >> On 2014-03-17 16:46, gmis...@gmail.com <javascript:> wrote:=20
> >>> You are right. It is that 0 is converting to a pointer for use in=20
> >>> relational operators that bites.=20
> >>> [...]=20
> >>> What I would like to see is that constant 0 not be convertible to a=
=20
> >>> pointer at least when used with relational operators.=20
> >>=20
> >> I'm not sure if that's possible as such.=20
> >=20
> > Why? g++ warns on it in my example, so why can't that be extended=20
> > further if we are so inclined?=20
>
> ...but it's "really" warning about comparison with 'nullptr'. I'm=20
> unconvinced that the implicit conversion of '0' to 'nullptr' can or=20
> should be prevented, even in this case. But...=20
>

But I'm not sure implicit conversion of literal 0 to nullptr is good? Why=
=20
do you think it's good?
=20

>
> >> What I think could be valuable,=20
> >> though, and might have the same (or at least similar) effect, would be=
=20
> >> to make ill-formed an ordering comparison (i.e. operators <, >, <=3D, =
>=3D)=20
> >> between a T* and nullptr_t.=20
> >=20
> > That sounds a lot like what I'm asking for so I'm not sure what=20
> > you were referring to above as "not sure that's possible" now.=20
>
> ...I believe we agree that the comparison should be prevented for=20
> nullptr, whether or not an implicit conversion from an integer 0=20
> constant occurred.=20
>
> (Maybe we're just experiencing terminology confusion? I may be=20
> misinterpreting where you wrote "constant 0" above, which I took to mean=
=20
> e.g. the 'literal string "0"' i.e. before implicit conversion to nullptr.=
)=20
>
> > I want to know why we can't harden compilers to have issues with this=
=20
> > statement:=20
> >       if (printf > 0)=20
>
> See previous comments. Right now, "0" here is implicitly converted to=20
> nullptr. So if we disallow operator< between T* and nullptr_t, we will=20
> disallow the above. (The only "gotcha" is to make sure that the "0"=20
> really does convert to "nullptr" and not "(T*)(0)"... and, apparently,=20
> to resolve that currently there is an overload ambiguity here, although=
=20
> given that we want it to be an error, resolving the ambiguity is rather=
=20
> superfluous.) =20


> All I'm saying is to not try to interfere with the conversion of "0" to=
=20
> nullptr and/or try to prevent the comparison before that conversion=20
> occurs. (Maybe that was also your intent as well, and I am just confused?=
)=20
>

These two paragraphs  sounds like the essence of what I'm most interested=
=20
in.=20

>
> I don't see a problem disallowing ordering comparisons between a pointer=
=20
> type and nullptr_t, and am in favor of doing so.=20
>
> > And require it to be specified in different terms, i.e. not of integer=
=20
> > 0, if that's really what they want, e.g.:=20
> >     if (printf > (appropriate type cast) nullptr)=20
>
> Right. Once the nullptr (whether it's spelled "nullptr" or "0") is=20
> coerced into an appropriate pointer type, the comparison would be=20
> allowed. (Needed for the general ordering case, as we already know.)=20
>
> > Yes the referring to nullptr as integer 0 is surprising=20
>
> I suspect the warning predates 'nullptr', and that when 'nullptr' was=20
> introduced, the conversion of "0" to "nullptr" is happening first, and=20
> the warning was changed to handle comparison between T* and nullptr_t,=20
> but the text was not updated accordingly.=20
>
> > but that's the whole problem with 0 and nullptr equating so easily=20
> > and in relational operators specifically I want to lessen that ease.=20
>
> Changing that implicit conversion in general would break compatibility.=
=20
> And I'd be uncomfortable treating 'a < 0' differently from 'a <=20
> nullptr'... besides that I'm inclined to disallow both of those.=20
>
> > clang doesn't warn on this usage at all and I think it should.=20
>
Yes I agree.

>
> Definitely. I'd file a bug report if you haven't already. (But that's OT=
=20
> for here.)=20
>
> > I think gcc's warning should be improved. Ideally I'd like to see it=20
> > warn on the lowest levels or error with such expressions.=20
>
> I don't think it's allowed to error by default=C2=B9 until/unless we chan=
ge=20
> the standard. This particular warning should probably have its own=20
> flag=C2=B2, though, and be on by default. Again, I encourage you to file =
a=20
> bug report :-).=20
>
Changing the standard is the reason I posted here. :)
I have referred the right honourable Richard Smith to this thread because=
=20
of this.


> (=C2=B9 If it errored by default, that would make the compiler=20
> non-conforming, which for obvious reasons I don't expect the devs to=20
> accept. Though I'm not sure, e.g. see the stuff that -fpermissive=20
> allows; maybe this could be a case for that.)=20
>
Really, this would be that bad?
Right is better than conforming to my mind, but I'm not selling compilers.

>
> (=C2=B2 The "own flag" is mainly/only because I suspect being on by defau=
lt=20
> mandates an independent flag so that it can be turned off.)=20
>
> --=20
> Matthew=20
>
> Thanks Matthew, I'm glad this discussion is receiving some attention.

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

<div dir=3D"ltr"><div><br>Hi</div><div><br>On Thursday, March 20, 2014 10:5=
9:26 AM UTC+13, Matthew Woehlke wrote:</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color=
: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">On=
 2014-03-19 16:58, <a onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"HbzpSw56lEIJ">gmis...@gmail.com</=
a> wrote:
<br>&gt; HI
<br>&gt;
<br>&gt; On Thursday, March 20, 2014 6:12:44 AM UTC+13, Matthew Woehlke wro=
te:
<br>&gt;&gt;
<br>&gt;&gt; On 2014-03-17 16:46, <a>gmis...@gmail.com</a> &lt;javascript:&=
gt; wrote:
<br>&gt;&gt;&gt; You are right. It is that 0 is converting to a pointer for=
 use in
<br>&gt;&gt;&gt; relational operators that bites.
<br>&gt;&gt;&gt; [...]
<br>&gt;&gt;&gt; What I would like to see is that constant 0 not be convert=
ible to a
<br>&gt;&gt;&gt; pointer at least when used with relational operators.
<br>&gt;&gt;
<br>&gt;&gt; I'm not sure if that's possible as such.
<br>&gt;
<br>&gt; Why? g++ warns on it in my example, so why can't that be extended
<br>&gt; further if we are so inclined?
<br>
<br>...but it's "really" warning about comparison with 'nullptr'. I'm=20
<br>unconvinced that the implicit conversion of '0' to 'nullptr' can or=20
<br>should be prevented, even in this case. But...
<br></blockquote><div><br></div><div><div>But I'm not sure&nbsp;implicit co=
nversion of literal 0 to nullptr is good? Why do you think it's good?</div>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">
<br>&gt;&gt; What I think could be valuable,
<br>&gt;&gt; though, and might have the same (or at least similar) effect, =
would be
<br>&gt;&gt; to make ill-formed an ordering comparison (i.e. operators &lt;=
, &gt;, &lt;=3D, &gt;=3D)
<br>&gt;&gt; between a T* and nullptr_t.
<br>&gt;
<br>&gt; That sounds a lot like what I'm asking for so I'm not sure what
<br>&gt; you were referring to above as "not sure that's possible" now.
<br>
<br>...I believe we agree that the comparison should be prevented for=20
<br>nullptr, whether or not an implicit conversion from an integer 0=20
<br>constant occurred.
<br>
<br>(Maybe we're just experiencing terminology confusion? I may be=20
<br>misinterpreting where you wrote "constant 0" above, which I took to mea=
n=20
<br>e.g. the 'literal string "0"' i.e. before implicit conversion to nullpt=
r.)
<br>
<br>&gt; I want to know why we can't harden compilers to have issues with t=
his
<br>&gt; statement:
<br>&gt; &nbsp; &nbsp; &nbsp; if (printf &gt; 0)
<br>
<br>See previous comments. Right now, "0" here is implicitly converted to=
=20
<br>nullptr. So if we disallow operator&lt; between T* and nullptr_t, we wi=
ll=20
<br>disallow the above. (The only "gotcha" is to make sure that the "0"=20
<br>really does convert to "nullptr" and not "(T*)(0)"... and, apparently,=
=20
<br>to resolve that currently there is an overload ambiguity here, although=
=20
<br>given that we want it to be an error, resolving the ambiguity is rather=
=20
<br>superfluous.)
&nbsp;</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">
<br>All I'm saying is to not try to interfere with the conversion of "0" to=
=20
<br>nullptr and/or try to prevent the comparison before that conversion=20
<br>occurs. (Maybe that was also your intent as well, and I am just confuse=
d?)
<br></blockquote><div><br></div><div>These two paragraphs&nbsp; sounds like=
 the essence of what I'm most interested in.&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">
<br>I don't see a problem disallowing ordering comparisons between a pointe=
r=20
<br>type and nullptr_t, and am in favor of doing so.
<br>
<br>&gt; And require it to be specified in different terms, i.e. not of int=
eger
<br>&gt; 0, if that's really what they want, e.g.:
<br>&gt; &nbsp; &nbsp; if (printf &gt; (appropriate type cast) nullptr)
<br>
<br>Right. Once the nullptr (whether it's spelled "nullptr" or "0") is=20
<br>coerced into an appropriate pointer type, the comparison would be=20
<br>allowed. (Needed for the general ordering case, as we already know.)
<br>
<br>&gt; Yes the referring to nullptr as integer 0 is surprising
<br>
<br>I suspect the warning predates 'nullptr', and that when 'nullptr' was=
=20
<br>introduced, the conversion of "0" to "nullptr" is happening first, and=
=20
<br>the warning was changed to handle comparison between T* and nullptr_t,=
=20
<br>but the text was not updated accordingly.
<br>
<br>&gt; but that's the whole problem with 0 and nullptr equating so easily
<br>&gt; and in relational operators specifically I want to lessen that eas=
e.
<br>
<br>Changing that implicit conversion in general would break compatibility.=
=20
<br>And I'd be uncomfortable treating 'a &lt; 0' differently from 'a &lt;=
=20
<br>nullptr'... besides that I'm inclined to disallow both of those.
<br>
<br>&gt; clang doesn't warn on this usage at all and I think it should.
<br></blockquote><div>Yes I agree.</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rg=
b(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>Definitely. I'd file a bug report if you haven't already. (But that's O=
T=20
<br>for here.)
<br>
<br>&gt; I think gcc's warning should be improved. Ideally I'd like to see =
it
<br>&gt; warn on the lowest levels or error with such expressions.
<br>
<br>I don't think it's allowed to error by default=C2=B9 until/unless we ch=
ange=20
<br>the standard. This particular warning should probably have its own=20
<br>flag=C2=B2, though, and be on by default. Again, I encourage you to fil=
e a=20
<br>bug report :-).
<br></blockquote><div>Changing the standard is the&nbsp;reason I&nbsp;poste=
d here. :)</div><div>I&nbsp;have referred the&nbsp;right honourable&nbsp;Ri=
chard Smith&nbsp;to this thread because of this.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;">
<br>(=C2=B9 If it errored by default, that would make the compiler=20
<br>non-conforming, which for obvious reasons I don't expect the devs to=20
<br>accept. Though I'm not sure, e.g. see the stuff that -fpermissive=20
<br>allows; maybe this could be a case for that.)
<br></blockquote><div>Really, this would be that bad?</div><div>Right is be=
tter than conforming to my mind, but I'm&nbsp;not selling compilers.</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddin=
g-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px;=
 border-left-style: solid;">
<br>(=C2=B2 The "own flag" is mainly/only because I suspect being on by def=
ault=20
<br>mandates an independent flag so that it can be turned off.)
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div>Thanks Matthew, I'm glad this discussion is receiving=
 some attention.</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_94_31835395.1395278612797--

.

On 2014-03-19 21:23, gmisocpp@gmail.com wrote:
> On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wrote:
>> ...but it's "really" warning about comparison with 'nullptr'. I'm
>> unconvinced that the implicit conversion of '0' to 'nullptr' can or
>> should be prevented, even in this case. But...
>
> But I'm not sure implicit conversion of literal 0 to nullptr is good? Why
> do you think it's good?

Honestly? It would probably make for cleaner code if we could deprecate=20
it. But that's the key word: "if". The amount of code that would break=20
by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=20
mixed with C++11 code without major (and sometimes near-impossible=C2=B9)=
=20
porting.

Realistically I don't see doing any such thing as being feasible for at=20
least ten years... probably more like fifteen to twenty.

(=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivially=
=20
changed by applications that want to use C++11 but build against a=20
pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=20
this is one I'm personally familiar with.)

>> See previous comments. Right now, "0" here is implicitly converted to
>> nullptr. So if we disallow operator< between T* and nullptr_t, we will
>> disallow the above. (The only "gotcha" is to make sure that the "0"
>> really does convert to "nullptr" and not "(T*)(0)"... and, apparently,
>> to resolve that currently there is an overload ambiguity here, although
>> given that we want it to be an error, resolving the ambiguity is rather
>> superfluous.)
>>
>> All I'm saying is to not try to interfere with the conversion of "0" to
>> nullptr and/or try to prevent the comparison before that conversion
>> occurs. (Maybe that was also your intent as well, and I am just confused=
?)
>
> These two paragraphs  sounds like the essence of what I'm most interested
> in.

Right; I think we're on the same page as far as disallowing comparison=20
against an effective literal nullptr, we're just nitpicking whether it=20
happens before or after implicit conversion of an integer 0 literal to=20
nullptr.

>> (=C2=B9 If [the compiler, absent a standard change] errored by default,
>>  that would make the compiler non-conforming, which for obvious
>> reasons I don't expect the devs to accept. Though I'm not sure,
>> e.g. see the stuff that -fpermissive allows; maybe this could be a
>> case for that.)
>
> Really, this would be that bad?
> Right is better than conforming to my mind, but I'm not selling compilers=
..

My knee-jerk reaction is that compiler vendors would rather be=20
conforming. Maybe I'm wrong. (Again, maybe this would be something where=20
e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
pedantically, the doc says that -fpermissive is for code that is=20
sometimes accepted even though it is non-conforming, whereas this is=20
rather the opposite.)

Still... I can only give my own impressions. If you want a worthwhile=20
opinion, take it up with the compiler vendors :-).

--=20
Matthew

--=20

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

.

On 2014-03-19 19:43, Jens Maurer wrote:
> On 03/20/2014 12:20 AM, Matthew Woehlke wrote:
>> IOW, this:
>>
>>     int* a = foo();
>>     if (a < nullptr)
>>       /*...*/;
>>
>> ...shall be a *compile error*, because operator<(int*, nullptr_t) is
>> disallowed.
>
> Just to be clear: The status quo in 5.9 converts "nullptr" to the
> type of "a" and is then happy to perform the comparison.  We need
> to disallow this conversion in case a nullptr_t is one of the operands
> of a relational operator.

Yes, that's exactly what I'm suggesting :-).

>>   But this:
>>
>>     int* a = foo(), b = nullptr;
>>     if (a < b)
>>       /*...*/;
>>
>> ...is not affected, because the type of both operands is int*, and we
>> aren't suggesting to change that case. Similarly, this:
>>
>>     int* a = foo();
>>     if (a < int*{nullptr})
>>       /*...*/;
>>
>> ...is also not affected for the same reason.
>
> In neither case, you can know at compile-time which value you're comparing
> with, so it cannot be ill-formed.

Well, you *could* (in theory) in the exact examples above, but the point
is that we *don't* want to do that optimization in order to forbid the
comparison; the use of explicit casting avoids the comparison being
ill-formed. Otherwise, for the general, you are correct, of course.

I think we're on the same page.

--
Matthew

--

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

.

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

Hi

On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:

> On 2014-03-19 21:23, gmis...@gmail.com <javascript:> wrote:=20
> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wrote:=
=20
> >> ...but it's "really" warning about comparison with 'nullptr'. I'm=20
> >> unconvinced that the implicit conversion of '0' to 'nullptr' can or=20
> >> should be prevented, even in this case. But...=20
> >=20
> > But I'm not sure implicit conversion of literal 0 to nullptr is good?=
=20
> Why=20
> > do you think it's good?=20
>
> Honestly? It would probably make for cleaner code if we could deprecate=
=20
> it. But that's the key word: "if". The amount of code that would break=20
> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=20
> mixed with C++11 code without major (and sometimes near-impossible=C2=B9)=
=20
> porting.=20
>
We don't know how much code we will break until we are sure exactly what=20
kind of statements we're considering breaking.
I'd find it easier if we talk the simplest statements we have problems=20
with, agree on that set than find out what else we'd break.
Agree first what we have problems with, separately from too much arguing=20
over the implications of changing it.

I'm not sure if everything I want to see is right or possible but I feel=20
sure some of it is right and possible and that we can improve things here,=
=20
even if a little.

What we need is a clear set of simple statements we all can broadly agree=
=20
are not ideal then see what the impact is of fixing them.
We need example statements. See below.


> Realistically I don't see doing any such thing as being feasible for at=
=20
> least ten years... probably more like fifteen to twenty.=20
>
> (=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be triviall=
y=20
> changed by applications that want to use C++11 but build against a=20
> pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=20
> this is one I'm personally familiar with.)=20
>
> >> See previous comments. Right now, "0" here is implicitly converted to=
=20
> >> nullptr. So if we disallow operator< between T* and nullptr_t, we will=
=20
> >> disallow the above. (The only "gotcha" is to make sure that the "0"=20
> >> really does convert to "nullptr" and not "(T*)(0)"... and, apparently,=
=20
> >> to resolve that currently there is an overload ambiguity here, althoug=
h=20
> >> given that we want it to be an error, resolving the ambiguity is rathe=
r=20
> >> superfluous.)=20
> >>=20
> >> All I'm saying is to not try to interfere with the conversion of "0" t=
o=20
> >> nullptr and/or try to prevent the comparison before that conversion=20
> >> occurs. (Maybe that was also your intent as well, and I am just=20
> confused?)=20
> >=20
> > These two paragraphs  sounds like the essence of what I'm most=20
> interested=20
> > in.=20
>
> Right; I think we're on the same page as far as disallowing comparison=20
> against an effective literal nullptr, we're just nitpicking whether it=20
> happens before or after implicit conversion of an integer 0 literal to=20
> nullptr.=20
>
> >> (=C2=B9 If [the compiler, absent a standard change] errored by default=
,=20
> >>  that would make the compiler non-conforming, which for obvious=20
> >> reasons I don't expect the devs to accept. Though I'm not sure,=20
> >> e.g. see the stuff that -fpermissive allows; maybe this could be a=20
> >> case for that.)=20
> >=20
> > Really, this would be that bad?=20
> > Right is better than conforming to my mind, but I'm not selling=20
> compilers.=20
>
> My knee-jerk reaction is that compiler vendors would rather be=20
> conforming. Maybe I'm wrong. (Again, maybe this would be something where=
=20
> e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
> pedantically, the doc says that -fpermissive is for code that is=20
> sometimes accepted even though it is non-conforming, whereas this is=20
> rather the opposite.)=20
>
> Still... I can only give my own impressions. If you want a worthwhile=20
> opinion, take it up with the compiler vendors :-).=20
>
> --=20
> Matthew=20
>
>
It's hard to talk about this subject because when you say something it's=20
easy accidentally or intentionally to say more and less than you mean.
So I'd like to start  focus on simple statements to see if we can agree if=
=20
they are dubious "as is", then worry separately what fixing it means to=20
other statements.
Or how much code it breaks.
Or how you actually fix it.

Then we can come back and look at it as a whole and narrow it done, give=20
up, or whatever. It makes it simpler to comprehend for people that aren't=
=20
language guru's.

So here's some examples:

#include <cstdio>=20
#include <cstddef>
using namespace std;
void fp(char*p) { }
void fn( nullptr_t np) { }
int main()
{
  char* p =3D nullptr; // I have no desire to break this.
  fp(nullptr); // No desire to break this
  fn(nullptr); // I have no desire to break.
  fn(0); // I'd like to break this. But what else will I break to get this?
  if (printf > 0) // I definitely want to break this. and <=3D etc.
     printf("Really?\n");
  if (printf > nullptr) // I think I'd like to break this "as is". What=20
else will I break to get this?
    printf("Maybe?");
}

Thanks=20

--=20

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

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

<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;">On 2014-03-19 21:23, <a onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1Sss3heQhMkJ">gmis...@gma=
il.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it's "really" warning about comparison with 'nullptr'. =
I'm
<br>&gt;&gt; unconvinced that the implicit conversion of '0' to 'nullptr' c=
an or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I'm not sure implicit conversion of literal 0 to nullptr is go=
od? Why
<br>&gt; do you think it's good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that's the key word: "if". The amount of code that would break=
=20
<br>by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
<br>'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=C2=
=B9)=20
<br>porting.
<br></blockquote><div>We don't know how much code we will break until we&nb=
sp;are&nbsp;sure exactly what kind of statements we're considering breaking=
..</div><div>I'd find it easier if we talk the simplest statements we have p=
roblems with, agree on that set&nbsp;than find out what else we'd break.</d=
iv><div>Agree first what we have problems with, separately from too much ar=
guing over the implications of changing it.</div><div><div><br></div></div>=
<div>I'm not sure if everything I want to see is right or possible but I fe=
el sure some of it is right&nbsp;and possible and that we can&nbsp;improve =
things here, even if a little.</div><div><br></div><div>What we need is a c=
lear set of simple statements we all can broadly agree are not ideal then s=
ee what the impact is of fixing them.</div><div>We need example statements.=
 See below.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;">
<br>Realistically I don't see doing any such thing as being feasible for at=
=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivia=
lly=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=
=20
<br>this is one I'm personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, "0" here is implicitly conve=
rted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only "gotcha" is to make sure that th=
e "0"
<br>&gt;&gt; really does convert to "nullptr" and not "(T*)(0)"... and, app=
arently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I'm saying is to not try to interfere with the conversion =
of "0" to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs &nbsp;sounds like the essence of what I'm mos=
t interested
<br>&gt; in.
<br>
<br>Right; I think we're on the same page as far as disallowing comparison=
=20
<br>against an effective literal nullptr, we're just nitpicking whether it=
=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=C2=B9 If [the compiler, absent a standard change] errored by=
 default,
<br>&gt;&gt; &nbsp;that would make the compiler non-conforming, which for o=
bvious
<br>&gt;&gt; reasons I don't expect the devs to accept. Though I'm not sure=
,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I'm not selling co=
mpilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I'm wrong. (Again, maybe this would be something wher=
e=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div><div>It's hard to talk about this subject b=
ecause when you say something it's easy accidentally or intentionally&nbsp;=
to say more and less than you mean.</div><div>So I'd like to start&nbsp; fo=
cus on simple&nbsp;statements&nbsp;to see if we can agree if they&nbsp;are =
dubious "as is", then worry separately what fixing it means to other statem=
ents.</div><div>Or how much code it breaks.</div><div>Or how you actually f=
ix it.</div><div><br></div><div>Then we can come back and look at it as a w=
hole and narrow it done, give up, or whatever. It makes it simpler to compr=
ehend for people that aren't language guru's.</div><div><br></div><div>So h=
ere's some examples:</div><div><br></div><div>#include &lt;cstdio&gt; <br>#=
include &lt;cstddef&gt;<br>using namespace std;<br>void fp(char*p) { }<br>v=
oid fn( nullptr_t np) { }</div><div>int main()<br>{<br>&nbsp; char* p =3D n=
ullptr; // I have no desire to break this.</div><div>&nbsp; fp(nullptr); //=
 No desire to break this<br>&nbsp; fn(nullptr); // I have no desire to brea=
k.<br>&nbsp; fn(0); // I'd like to break this. But what else will I break t=
o get this?<br>&nbsp; if (printf &gt; 0) // I definitely want to break this=
.. and &lt;=3D etc.<br>&nbsp;&nbsp;&nbsp; &nbsp;printf("Really?\n");<br>&nbs=
p; if (printf &gt; nullptr) // I think I'd like to break this "as is". What=
 else will I break to get this?<br>&nbsp; &nbsp; printf("Maybe?");<br>}</di=
v><div><br></div><div>Thanks&nbsp;</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_1203_24179456.1395347242542--

.

On 2014-03-20 16:27, gmisocpp@gmail.com wrote:
> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>> On 2014-03-19 21:23, gmis...@gmail.com <javascript:> wrote:
>>> But I'm not sure implicit conversion of literal 0 to nullptr is good?
>>> Why do you think it's good?
>>
>> Honestly? It would probably make for cleaner code if we could deprecate
>> it. But that's the key word: "if". The amount of code that would break
>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean
>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be
>> mixed with C++11 code without major (and sometimes near-impossible=C2=B9=
)
>> porting.
>
> We don't know how much code we will break until we are sure exactly what
> kind of statements we're considering breaking.

Just offhand, I *know* that removing implicit conversion of "0" to a=20
pointer type will break all Qt4 code in existence. I'd be *very*=20
surprised if the breakage isn't massive and widespread.

>    void fp(char* p) { }
>    void fn(nullptr_t np) { }
>    fn(0); // I'd like to break this. But what else will I break to get th=
is?

Do you also break 'fp(0)'? If yes, you break most code that was written=20
before C++11, or belongs to projects started before C++11. IMHO this is=20
completely unacceptable.

Even if no, I think it would be confusing that '0' converts to 'nullptr'=20
in order to convert to a concrete pointer type, but *not* if the=20
required type is nullptr_t. I'd be opposed to that, and I'd expect many=20
other folks would be also.

>    if (printf > 0) // I definitely want to break this. and <=3D etc.

Agreed. But...

>    if (printf > nullptr) // I think I'd like to break this "as is".

....I'd break this too. IMO this makes no more sense than the above (and=20
as has been pointed out, the result is explicitly unspecified by the=20
standard) and should also be disallowed.

--=20
Matthew

--=20

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

.

--089e013a0f8a8b822704f51078e1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 20, 2014 at 1:27 PM, <gmisocpp@gmail.com> wrote:

> Hi
>
> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>
>> On 2014-03-19 21:23, gmis...@gmail.com wrote:
>> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wrote:
>> >> ...but it's "really" warning about comparison with 'nullptr'. I'm
>> >> unconvinced that the implicit conversion of '0' to 'nullptr' can or
>> >> should be prevented, even in this case. But...
>> >
>> > But I'm not sure implicit conversion of literal 0 to nullptr is good?
>> Why
>> > do you think it's good?
>>
>> Honestly? It would probably make for cleaner code if we could deprecate
>> it. But that's the key word: "if". The amount of code that would break
>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean
>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be
>> mixed with C++11 code without major (and sometimes near-impossible=B9)
>> porting.
>>
> We don't know how much code we will break until we are sure exactly what
> kind of statements we're considering breaking.
> I'd find it easier if we talk the simplest statements we have problems
> with, agree on that set than find out what else we'd break.
> Agree first what we have problems with, separately from too much arguing
> over the implications of changing it.
>
> I'm not sure if everything I want to see is right or possible but I feel
> sure some of it is right and possible and that we can improve things here=
,
> even if a little.
>
> What we need is a clear set of simple statements we all can broadly agree
> are not ideal then see what the impact is of fixing them.
> We need example statements. See below.
>
>
>> Realistically I don't see doing any such thing as being feasible for at
>> least ten years... probably more like fifteen to twenty.
>>
>> (=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivially
>> changed by applications that want to use C++11 but build against a
>> pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;
>> this is one I'm personally familiar with.)
>>
>> >> See previous comments. Right now, "0" here is implicitly converted to
>> >> nullptr. So if we disallow operator< between T* and nullptr_t, we wil=
l
>> >> disallow the above. (The only "gotcha" is to make sure that the "0"
>> >> really does convert to "nullptr" and not "(T*)(0)"... and, apparently=
,
>> >> to resolve that currently there is an overload ambiguity here,
>> although
>> >> given that we want it to be an error, resolving the ambiguity is
>> rather
>> >> superfluous.)
>> >>
>> >> All I'm saying is to not try to interfere with the conversion of "0"
>> to
>> >> nullptr and/or try to prevent the comparison before that conversion
>> >> occurs. (Maybe that was also your intent as well, and I am just
>> confused?)
>> >
>> > These two paragraphs  sounds like the essence of what I'm most
>> interested
>> > in.
>>
>> Right; I think we're on the same page as far as disallowing comparison
>> against an effective literal nullptr, we're just nitpicking whether it
>> happens before or after implicit conversion of an integer 0 literal to
>> nullptr.
>>
>> >> (=B9 If [the compiler, absent a standard change] errored by default,
>> >>  that would make the compiler non-conforming, which for obvious
>> >> reasons I don't expect the devs to accept. Though I'm not sure,
>> >> e.g. see the stuff that -fpermissive allows; maybe this could be a
>> >> case for that.)
>> >
>> > Really, this would be that bad?
>> > Right is better than conforming to my mind, but I'm not selling
>> compilers.
>>
>> My knee-jerk reaction is that compiler vendors would rather be
>> conforming. Maybe I'm wrong. (Again, maybe this would be something where
>> e.g. gcc would be okay disallowing it without -fpermissive. Though,
>> pedantically, the doc says that -fpermissive is for code that is
>> sometimes accepted even though it is non-conforming, whereas this is
>> rather the opposite.)
>>
>> Still... I can only give my own impressions. If you want a worthwhile
>> opinion, take it up with the compiler vendors :-).
>>
>> --
>> Matthew
>>
>>
> It's hard to talk about this subject because when you say something it's
> easy accidentally or intentionally to say more and less than you mean.
> So I'd like to start  focus on simple statements to see if we can agree i=
f
> they are dubious "as is", then worry separately what fixing it means to
> other statements.
> Or how much code it breaks.
> Or how you actually fix it.
>
> Then we can come back and look at it as a whole and narrow it done, give
> up, or whatever. It makes it simpler to comprehend for people that aren't
> language guru's.
>
> So here's some examples:
>
> #include <cstdio>
> #include <cstddef>
> using namespace std;
> void fp(char*p) { }
> void fn( nullptr_t np) { }
> int main()
> {
>   char* p =3D nullptr; // I have no desire to break this.
>   fp(nullptr); // No desire to break this
>   fn(nullptr); // I have no desire to break.
>   fn(0); // I'd like to break this. But what else will I break to get thi=
s?
>

A guiding principle we've been using is that std::nullptr_t acts basically
like a pointer type (so that, for instance, you can use it as a template
argument in a template that wants something like a pointer type). For that
reason, I suspect there will be opposition to making this ill-formed.


>   if (printf > 0) // I definitely want to break this. and <=3D etc.
>      printf("Really?\n");
>   if (printf > nullptr) // I think I'd like to break this "as is". What
> else will I break to get this?
>

These are already ill-formed, per DR583. See:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#583
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3478.html

I'm not sure if any compiler implements this DR yet.

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

--089e013a0f8a8b822704f51078e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 20, 2014 at 1:27 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><div class=3D""><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid">
On 2014-03-19 21:23, <a>gmis...@gmail.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it&#39;s &quot;really&quot; warning about comparison wi=
th &#39;nullptr&#39;. I&#39;m
<br>&gt;&gt; unconvinced that the implicit conversion of &#39;0&#39; to &#3=
9;nullptr&#39; can or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I&#39;m not sure implicit conversion of literal 0 to nullptr i=
s good? Why
<br>&gt; do you think it&#39;s good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that&#39;s the key word: &quot;if&quot;. The amount of code tha=
t would break=20
<br>by doing so is appalling, as *all* pre-C++11 code uses &#39;0&#39; to m=
ean=20
<br>&#39;nullptr&#39;. Thus it is &quot;good&quot; in that it allows pre-C+=
+11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=B9)=
=20
<br>porting.
<br></blockquote></div><div>We don&#39;t know how much code we will break u=
ntil we=A0are=A0sure exactly what kind of statements we&#39;re considering =
breaking.</div><div>I&#39;d find it easier if we talk the simplest statemen=
ts we have problems with, agree on that set=A0than find out what else we&#3=
9;d break.</div>
<div>Agree first what we have problems with, separately from too much argui=
ng over the implications of changing it.</div><div><div><br></div></div><di=
v>I&#39;m not sure if everything I want to see is right or possible but I f=
eel sure some of it is right=A0and possible and that we can=A0improve thing=
s here, even if a little.</div>
<div><br></div><div>What we need is a clear set of simple statements we all=
 can broadly agree are not ideal then see what the impact is of fixing them=
..</div><div>We need example statements. See below.</div><div><div class=3D"=
h5">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">
<br>Realistically I don&#39;t see doing any such thing as being feasible fo=
r at=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=B9 e.g. use of &#39;0&#39; as &#39;nullptr&#39; in Qt macros which ca=
n&#39;t be trivially=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-&#39;nullptr&#39;-correct Qt. I&#39;m sure there are other, similar=
 examples;=20
<br>this is one I&#39;m personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, &quot;0&quot; here is implic=
itly converted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only &quot;gotcha&quot; is to make su=
re that the &quot;0&quot;
<br>&gt;&gt; really does convert to &quot;nullptr&quot; and not &quot;(T*)(=
0)&quot;... and, apparently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I&#39;m saying is to not try to interfere with the convers=
ion of &quot;0&quot; to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs =A0sounds like the essence of what I&#39;m mo=
st interested
<br>&gt; in.
<br>
<br>Right; I think we&#39;re on the same page as far as disallowing compari=
son=20
<br>against an effective literal nullptr, we&#39;re just nitpicking whether=
 it=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=B9 If [the compiler, absent a standard change] errored by de=
fault,
<br>&gt;&gt; =A0that would make the compiler non-conforming, which for obvi=
ous
<br>&gt;&gt; reasons I don&#39;t expect the devs to accept. Though I&#39;m =
not sure,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I&#39;m not sellin=
g compilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I&#39;m wrong. (Again, maybe this would be something =
where=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div></div></div><div>It&#39;s hard to talk abou=
t this subject because when you say something it&#39;s easy accidentally or=
 intentionally=A0to say more and less than you mean.</div><div>So I&#39;d l=
ike to start=A0 focus on simple=A0statements=A0to see if we can agree if th=
ey=A0are dubious &quot;as is&quot;, then worry separately what fixing it me=
ans to other statements.</div>
<div>Or how much code it breaks.</div><div>Or how you actually fix it.</div=
><div><br></div><div>Then we can come back and look at it as a whole and na=
rrow it done, give up, or whatever. It makes it simpler to comprehend for p=
eople that aren&#39;t language guru&#39;s.</div>
<div><br></div><div>So here&#39;s some examples:</div><div><br></div><div>#=
include &lt;cstdio&gt; <br>#include &lt;cstddef&gt;<br>using namespace std;=
<br>void fp(char*p) { }<br>void fn( nullptr_t np) { }</div><div>int main()<=
br>
{<br>=A0 char* p =3D nullptr; // I have no desire to break this.</div><div>=
=A0 fp(nullptr); // No desire to break this<br>=A0 fn(nullptr); // I have n=
o desire to break.<br>=A0 fn(0); // I&#39;d like to break this. But what el=
se will I break to get this?<br>
</div></div></blockquote><div><br></div><div>A guiding principle we&#39;ve =
been using is that std::nullptr_t acts basically like a pointer type (so th=
at, for instance, you can use it as a template argument in a template that =
wants something like a pointer type). For that reason, I suspect there will=
 be opposition to making this ill-formed.</div>
<div>=A0</div><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>=A0 if (printf &gt; 0)=
 // I definitely want to break this. and &lt;=3D etc.<br>
=A0=A0=A0 =A0printf(&quot;Really?\n&quot;);<br>=A0 if (printf &gt; nullptr)=
 // I think I&#39;d like to break this &quot;as is&quot;. What else will I =
break to get this?<br></div></div></blockquote><div><br></div><div>These ar=
e already ill-formed, per DR583. See:</div>
<div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
cwg_defects.html#583">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defec=
ts.html#583</a><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2012/n3478.html">http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2012/n3478.html</a><br>
</div><div><br></div><div>I&#39;m not sure if any compiler implements this =
DR yet.</div></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 />

--089e013a0f8a8b822704f51078e1--

.

On 2014-03-20 17:29, Richard Smith wrote:
> On Thu, Mar 20, 2014 at 1:27 PM, <gmisocpp@gmail.com> wrote:
>>    if (printf > 0) // I definitely want to break this. and <= etc.
>>       printf("Really?\n");
>>    if (printf > nullptr) // I think I'd like to break this "as is". What
>> else will I break to get this?
>
> These are already ill-formed, per DR583. See:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#583
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3478.html

Ah! Well... how 'bout that. Thanks for pointing this out!

--
Matthew

--

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

.

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

Hi Richard

On Friday, March 21, 2014 10:29:57 AM UTC+13, Richard Smith wrote:
>
> On Thu, Mar 20, 2014 at 1:27 PM, <gmis...@gmail.com <javascript:>> wrote:
>
>> Hi
>>
>> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>>
>>> On 2014-03-19 21:23, gmis...@gmail.com wrote:=20
>>> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wrote=
:=20
>>> >> ...but it's "really" warning about comparison with 'nullptr'. I'm=20
>>> >> unconvinced that the implicit conversion of '0' to 'nullptr' can or=
=20
>>> >> should be prevented, even in this case. But...=20
>>> >=20
>>> > But I'm not sure implicit conversion of literal 0 to nullptr is good?=
=20
>>> Why=20
>>> > do you think it's good?=20
>>>
>>> Honestly? It would probably make for cleaner code if we could deprecate=
=20
>>> it. But that's the key word: "if". The amount of code that would break=
=20
>>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
>>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=20
>>> mixed with C++11 code without major (and sometimes near-impossible=C2=
=B9)=20
>>> porting.=20
>>>
>> We don't know how much code we will break until we are sure exactly what=
=20
>> kind of statements we're considering breaking.
>> I'd find it easier if we talk the simplest statements we have problems=
=20
>> with, agree on that set than find out what else we'd break.
>> Agree first what we have problems with, separately from too much arguing=
=20
>> over the implications of changing it.
>>
>> I'm not sure if everything I want to see is right or possible but I feel=
=20
>> sure some of it is right and possible and that we can improve things her=
e,=20
>> even if a little.
>>
>> What we need is a clear set of simple statements we all can broadly agre=
e=20
>> are not ideal then see what the impact is of fixing them.
>> We need example statements. See below.
>>
>>
>>> Realistically I don't see doing any such thing as being feasible for at=
=20
>>> least ten years... probably more like fifteen to twenty.=20
>>>
>>> (=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivia=
lly=20
>>> changed by applications that want to use C++11 but build against a=20
>>> pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=
=20
>>> this is one I'm personally familiar with.)=20
>>>
>>> >> See previous comments. Right now, "0" here is implicitly converted t=
o=20
>>> >> nullptr. So if we disallow operator< between T* and nullptr_t, we=20
>>> will=20
>>> >> disallow the above. (The only "gotcha" is to make sure that the "0"=
=20
>>> >> really does convert to "nullptr" and not "(T*)(0)"... and,=20
>>> apparently,=20
>>> >> to resolve that currently there is an overload ambiguity here,=20
>>> although=20
>>> >> given that we want it to be an error, resolving the ambiguity is=20
>>> rather=20
>>> >> superfluous.)=20
>>> >>=20
>>> >> All I'm saying is to not try to interfere with the conversion of "0"=
=20
>>> to=20
>>> >> nullptr and/or try to prevent the comparison before that conversion=
=20
>>> >> occurs. (Maybe that was also your intent as well, and I am just=20
>>> confused?)=20
>>> >=20
>>> > These two paragraphs  sounds like the essence of what I'm most=20
>>> interested=20
>>> > in.=20
>>>
>>> Right; I think we're on the same page as far as disallowing comparison=
=20
>>> against an effective literal nullptr, we're just nitpicking whether it=
=20
>>> happens before or after implicit conversion of an integer 0 literal to=
=20
>>> nullptr.=20
>>>
>>> >> (=C2=B9 If [the compiler, absent a standard change] errored by defau=
lt,=20
>>> >>  that would make the compiler non-conforming, which for obvious=20
>>> >> reasons I don't expect the devs to accept. Though I'm not sure,=20
>>> >> e.g. see the stuff that -fpermissive allows; maybe this could be a=
=20
>>> >> case for that.)=20
>>> >=20
>>> > Really, this would be that bad?=20
>>> > Right is better than conforming to my mind, but I'm not selling=20
>>> compilers.=20
>>>
>>> My knee-jerk reaction is that compiler vendors would rather be=20
>>> conforming. Maybe I'm wrong. (Again, maybe this would be something wher=
e=20
>>> e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
>>> pedantically, the doc says that -fpermissive is for code that is=20
>>> sometimes accepted even though it is non-conforming, whereas this is=20
>>> rather the opposite.)=20
>>>
>>> Still... I can only give my own impressions. If you want a worthwhile=
=20
>>> opinion, take it up with the compiler vendors :-).=20
>>>
>>> --=20
>>> Matthew=20
>>>
>>>
>> It's hard to talk about this subject because when you say something it's=
=20
>> easy accidentally or intentionally to say more and less than you mean.
>> So I'd like to start  focus on simple statements to see if we can agree=
=20
>> if they are dubious "as is", then worry separately what fixing it means =
to=20
>> other statements.
>> Or how much code it breaks.
>> Or how you actually fix it.
>>
>> Then we can come back and look at it as a whole and narrow it done, give=
=20
>> up, or whatever. It makes it simpler to comprehend for people that aren'=
t=20
>> language guru's.
>>
>> So here's some examples:
>>
>> #include <cstdio>=20
>> #include <cstddef>
>> using namespace std;
>> void fp(char*p) { }
>> void fn( nullptr_t np) { }
>> int main()
>> {
>>   char* p =3D nullptr; // I have no desire to break this.
>>   fp(nullptr); // No desire to break this
>>   fn(nullptr); // I have no desire to break.
>>   fn(0); // I'd like to break this. But what else will I break to get=20
>> this?
>>
>
> A guiding principle we've been using is that std::nullptr_t acts basicall=
y=20
> like a pointer type (so that, for instance, you can use it as a template=
=20
> argument in a template that wants something like a pointer type). For tha=
t=20
> reason, I suspect there will be opposition to making this ill-formed.
> =20
>
>>   if (printf > 0) // I definitely want to break this. and <=3D etc.
>>      printf("Really?\n");
>>   if (printf > nullptr) // I think I'd like to break this "as is". What=
=20
>> else will I break to get this?
>>
>
> These are already ill-formed, per DR583. See:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#583
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3478.html
>
> I'm not sure if any compiler implements this DR yet.
>

Wonderful! I have a feeling of euphoria that C++ isn't quite so mad as to=
=20
despair for it, but just mad enough to love.

Thanks that's great.

What does that mean for this though?:

void f(nullptr_t);
f(0); // I'd like not to allow this, I think.

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

<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 10:29:57 AM UT=
C+13, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 1:27 PM,  <span dir=3D=
"ltr">&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"qILIq5MzweMJ">gmis...@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">
On 2014-03-19 21:23, <a>gmis...@gmail.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it's "really" warning about comparison with 'nullptr'. =
I'm
<br>&gt;&gt; unconvinced that the implicit conversion of '0' to 'nullptr' c=
an or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I'm not sure implicit conversion of literal 0 to nullptr is go=
od? Why
<br>&gt; do you think it's good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that's the key word: "if". The amount of code that would break=
=20
<br>by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
<br>'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=C2=
=B9)=20
<br>porting.
<br></blockquote></div><div>We don't know how much code we will break until=
 we&nbsp;are&nbsp;sure exactly what kind of statements we're considering br=
eaking.</div><div>I'd find it easier if we talk the simplest statements we =
have problems with, agree on that set&nbsp;than find out what else we'd bre=
ak.</div>
<div>Agree first what we have problems with, separately from too much argui=
ng over the implications of changing it.</div><div><div><br></div></div><di=
v>I'm not sure if everything I want to see is right or possible but I feel =
sure some of it is right&nbsp;and possible and that we can&nbsp;improve thi=
ngs here, even if a little.</div>
<div><br></div><div>What we need is a clear set of simple statements we all=
 can broadly agree are not ideal then see what the impact is of fixing them=
..</div><div>We need example statements. See below.</div><div><div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">
<br>Realistically I don't see doing any such thing as being feasible for at=
=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivia=
lly=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=
=20
<br>this is one I'm personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, "0" here is implicitly conve=
rted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only "gotcha" is to make sure that th=
e "0"
<br>&gt;&gt; really does convert to "nullptr" and not "(T*)(0)"... and, app=
arently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I'm saying is to not try to interfere with the conversion =
of "0" to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs &nbsp;sounds like the essence of what I'm mos=
t interested
<br>&gt; in.
<br>
<br>Right; I think we're on the same page as far as disallowing comparison=
=20
<br>against an effective literal nullptr, we're just nitpicking whether it=
=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=C2=B9 If [the compiler, absent a standard change] errored by=
 default,
<br>&gt;&gt; &nbsp;that would make the compiler non-conforming, which for o=
bvious
<br>&gt;&gt; reasons I don't expect the devs to accept. Though I'm not sure=
,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I'm not selling co=
mpilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I'm wrong. (Again, maybe this would be something wher=
e=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div></div></div><div>It's hard to talk about th=
is subject because when you say something it's easy accidentally or intenti=
onally&nbsp;to say more and less than you mean.</div><div>So I'd like to st=
art&nbsp; focus on simple&nbsp;statements&nbsp;to see if we can agree if th=
ey&nbsp;are dubious "as is", then worry separately what fixing it means to =
other statements.</div>
<div>Or how much code it breaks.</div><div>Or how you actually fix it.</div=
><div><br></div><div>Then we can come back and look at it as a whole and na=
rrow it done, give up, or whatever. It makes it simpler to comprehend for p=
eople that aren't language guru's.</div>
<div><br></div><div>So here's some examples:</div><div><br></div><div>#incl=
ude &lt;cstdio&gt; <br>#include &lt;cstddef&gt;<br>using namespace std;<br>=
void fp(char*p) { }<br>void fn( nullptr_t np) { }</div><div>int main()<br>
{<br>&nbsp; char* p =3D nullptr; // I have no desire to break this.</div><d=
iv>&nbsp; fp(nullptr); // No desire to break this<br>&nbsp; fn(nullptr); //=
 I have no desire to break.<br>&nbsp; fn(0); // I'd like to break this. But=
 what else will I break to get this?<br>
</div></div></blockquote><div><br></div><div>A guiding principle we've been=
 using is that std::nullptr_t acts basically like a pointer type (so that, =
for instance, you can use it as a template argument in a template that want=
s something like a pointer type). For that reason, I suspect there will be =
opposition to making this ill-formed.</div>
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>&nbsp; =
if (printf &gt; 0) // I definitely want to break this. and &lt;=3D etc.<br>
&nbsp;&nbsp;&nbsp; &nbsp;printf("Really?\n");<br>&nbsp; if (printf &gt; nul=
lptr) // I think I'd like to break this "as is". What else will I break to =
get this?<br></div></div></blockquote><div><br></div><div>These are already=
 ill-formed, per DR583. See:</div>
<div><br></div><div><a onmousedown=3D"this.href=3D'http://www.google.com/ur=
l?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defec=
ts.html%23583\46sa\75D\46sntz\0751\46usg\75AFQjCNHgI_T6c5ED5YcO52M4tupMJp6q=
DA';return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%2=
3583\46sa\75D\46sntz\0751\46usg\75AFQjCNHgI_T6c5ED5YcO52M4tupMJp6qDA';retur=
n true;" href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.ht=
ml#583" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/=
cwg_defects.<wbr>html#583</a><br></div><div><a onmousedown=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2=
Fwg21%2Fdocs%2Fpapers%2F2012%2Fn3478.html\46sa\75D\46sntz\0751\46usg\75AFQj=
CNEIYS4UTAAIvMUEX6LMGIPM_Vq2FA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2012%2Fn3478.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEIY=
S4UTAAIvMUEX6LMGIPM_Vq2FA';return true;" href=3D"http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2012/n3478.html" target=3D"_blank">http://www.open=
-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2012/<wbr>n3478.html</a><br>
</div><div><br></div><div>I'm not sure if any compiler implements this DR y=
et.</div></div></div></div></blockquote><div><br></div><div>Wonderful! I ha=
ve a feeling of&nbsp;euphoria&nbsp;that C++ isn't quite so mad as to despai=
r for it, but just mad enough to love.</div><div><br></div><div>Thanks that=
's great.</div><div><br></div><div>What does that mean for this though?:</d=
iv><div><br></div><div>void f(nullptr_t);</div><div>f(0); // I'd like not t=
o allow this, I think.</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_1329_8519879.1395353313208--

.

------=_Part_1300_590837.1395353800730
Content-Type: text/plain; charset=UTF-8


>
> Hi
>
<snip>

> >    void fp(char* p) { }
> >    void fn(nullptr_t np) { }
> >    fn(0); // I'd like to break this. But what else will I break to get
> this?
>
> Do you also break 'fp(0)'? If yes, you break most code that was written
> before C++11, or belongs to projects started before C++11. IMHO this is
> completely unacceptable.
>

No I'm not proposing to break fp(0) as much as I'd like to.
I don't remotely see that as possible, yet.

I would like to see conversion tools become more widespread that will
convert that to nullptr in a smart way.
I don't no if it can be deprecated with a 100 year life time or something
before removal.
Warnings that would complain about it would be nice. They probably exist.
I am proposing to break fn(0);

>
> Even if no, I think it would be confusing that '0' converts to 'nullptr'
> in order to convert to a concrete pointer type, but *not* if the
> required type is nullptr_t. I'd be opposed to that, and I'd expect many
> other folks would be also.
>
> >    if (printf > 0) // I definitely want to break this. and <= etc.
>
> Agreed. But...
>
> >    if (printf > nullptr) // I think I'd like to break this "as is".
>
> ...I'd break this too. IMO this makes no more sense than the above (and
> as has been pointed out, the result is explicitly unspecified by the
> standard) and should also be disallowed.
>
> --
> Matthew
>
> Btw, Richards reply was news to me, and great news.
clang/libcxx doesn't support much of this yet that AFAIKT (nor does g++ or
cl), but I have a feeling clang will do before I finish type this sentence.
lol

Thanks

--

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;">Hi<br></blockquote><div>&lt;s=
nip&gt;&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">&gt; &nbsp; &nbsp;void fp(c=
har* p) { }
<br>&gt; &nbsp; &nbsp;void fn(nullptr_t np) { }
<br>&gt; &nbsp; &nbsp;fn(0); // I'd like to break this. But what else will =
I break to get this?
<br>
<br>Do you also break 'fp(0)'? If yes, you break most code that was written=
=20
<br>before C++11, or belongs to projects started before C++11. IMHO this is=
=20
<br>completely unacceptable.
<br></blockquote><div><br></div><div>No I'm not proposing to break fp(0) as=
 much as I'd like to.</div><div><div>I don't remotely see that&nbsp;as poss=
ible, yet.</div></div><div><br></div><div>I would like to see conversion to=
ols become more widespread that will convert that to nullptr in a smart way=
..</div><div>I don't no if it can be deprecated with a&nbsp;100 year life ti=
me or something before removal.</div><div>Warnings that would complain abou=
t it would be nice. They probably exist.</div><div>I am proposing to break =
fn(0);</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">
<br>Even if no, I think it would be confusing that '0' converts to 'nullptr=
'=20
<br>in order to convert to a concrete pointer type, but *not* if the=20
<br>required type is nullptr_t. I'd be opposed to that, and I'd expect many=
=20
<br>other folks would be also.
<br>
<br>&gt; &nbsp; &nbsp;if (printf &gt; 0) // I definitely want to break this=
.. and &lt;=3D etc.
<br>
<br>Agreed. But...
<br>
<br>&gt; &nbsp; &nbsp;if (printf &gt; nullptr) // I think I'd like to break=
 this "as is".
<br>
<br>...I'd break this too. IMO this makes no more sense than the above (and=
=20
<br>as has been pointed out, the result is explicitly unspecified by the=20
<br>standard) and should also be disallowed.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div>Btw, Richards reply was news to me, and great news.</=
div><div>clang/libcxx doesn't support&nbsp;much of this yet&nbsp;that AFAIK=
T (nor does g++ or cl), but I have a feeling&nbsp;clang will do before I fi=
nish type this sentence. lol</div><div>&nbsp;</div><div>Thanks&nbsp;</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_1300_590837.1395353800730--

.

--047d7b671f3477ae5704f511dc97
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 20, 2014 at 3:08 PM, <gmisocpp@gmail.com> wrote:

> Hi Richard
>
> On Friday, March 21, 2014 10:29:57 AM UTC+13, Richard Smith wrote:
>
>> On Thu, Mar 20, 2014 at 1:27 PM, <gmis...@gmail.com> wrote:
>>
>>> Hi
>>>
>>> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>>>
>>>> On 2014-03-19 21:23, gmis...@gmail.com wrote:
>>>> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke
>>>> wrote:
>>>> >> ...but it's "really" warning about comparison with 'nullptr'. I'm
>>>> >> unconvinced that the implicit conversion of '0' to 'nullptr' can or
>>>> >> should be prevented, even in this case. But...
>>>> >
>>>> > But I'm not sure implicit conversion of literal 0 to nullptr is good=
?
>>>> Why
>>>> > do you think it's good?
>>>>
>>>> Honestly? It would probably make for cleaner code if we could deprecat=
e
>>>> it. But that's the key word: "if". The amount of code that would break
>>>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean
>>>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be
>>>> mixed with C++11 code without major (and sometimes near-impossible=B9)
>>>> porting.
>>>>
>>> We don't know how much code we will break until we are sure exactly wha=
t
>>> kind of statements we're considering breaking.
>>> I'd find it easier if we talk the simplest statements we have problems
>>> with, agree on that set than find out what else we'd break.
>>> Agree first what we have problems with, separately from too much arguin=
g
>>> over the implications of changing it.
>>>
>>> I'm not sure if everything I want to see is right or possible but I fee=
l
>>> sure some of it is right and possible and that we can improve things he=
re,
>>> even if a little.
>>>
>>> What we need is a clear set of simple statements we all can broadly
>>> agree are not ideal then see what the impact is of fixing them.
>>> We need example statements. See below.
>>>
>>>
>>>> Realistically I don't see doing any such thing as being feasible for a=
t
>>>> least ten years... probably more like fifteen to twenty.
>>>>
>>>> (=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be triviall=
y
>>>> changed by applications that want to use C++11 but build against a
>>>> pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;
>>>> this is one I'm personally familiar with.)
>>>>
>>>> >> See previous comments. Right now, "0" here is implicitly converted
>>>> to
>>>> >> nullptr. So if we disallow operator< between T* and nullptr_t, we
>>>> will
>>>> >> disallow the above. (The only "gotcha" is to make sure that the "0"
>>>> >> really does convert to "nullptr" and not "(T*)(0)"... and,
>>>> apparently,
>>>> >> to resolve that currently there is an overload ambiguity here,
>>>> although
>>>> >> given that we want it to be an error, resolving the ambiguity is
>>>> rather
>>>> >> superfluous.)
>>>> >>
>>>> >> All I'm saying is to not try to interfere with the conversion of "0=
"
>>>> to
>>>> >> nullptr and/or try to prevent the comparison before that conversion
>>>> >> occurs. (Maybe that was also your intent as well, and I am just
>>>> confused?)
>>>> >
>>>> > These two paragraphs  sounds like the essence of what I'm most
>>>> interested
>>>> > in.
>>>>
>>>> Right; I think we're on the same page as far as disallowing comparison
>>>> against an effective literal nullptr, we're just nitpicking whether it
>>>> happens before or after implicit conversion of an integer 0 literal to
>>>> nullptr.
>>>>
>>>> >> (=B9 If [the compiler, absent a standard change] errored by default=
,
>>>> >>  that would make the compiler non-conforming, which for obvious
>>>> >> reasons I don't expect the devs to accept. Though I'm not sure,
>>>> >> e.g. see the stuff that -fpermissive allows; maybe this could be a
>>>> >> case for that.)
>>>> >
>>>> > Really, this would be that bad?
>>>> > Right is better than conforming to my mind, but I'm not selling
>>>> compilers.
>>>>
>>>> My knee-jerk reaction is that compiler vendors would rather be
>>>> conforming. Maybe I'm wrong. (Again, maybe this would be something
>>>> where
>>>> e.g. gcc would be okay disallowing it without -fpermissive. Though,
>>>> pedantically, the doc says that -fpermissive is for code that is
>>>> sometimes accepted even though it is non-conforming, whereas this is
>>>> rather the opposite.)
>>>>
>>>> Still... I can only give my own impressions. If you want a worthwhile
>>>> opinion, take it up with the compiler vendors :-).
>>>>
>>>> --
>>>> Matthew
>>>>
>>>>
>>> It's hard to talk about this subject because when you say something it'=
s
>>> easy accidentally or intentionally to say more and less than you mean.
>>> So I'd like to start  focus on simple statements to see if we can agree
>>> if they are dubious "as is", then worry separately what fixing it means=
 to
>>> other statements.
>>> Or how much code it breaks.
>>> Or how you actually fix it.
>>>
>>> Then we can come back and look at it as a whole and narrow it done, giv=
e
>>> up, or whatever. It makes it simpler to comprehend for people that aren=
't
>>> language guru's.
>>>
>>> So here's some examples:
>>>
>>> #include <cstdio>
>>> #include <cstddef>
>>> using namespace std;
>>> void fp(char*p) { }
>>> void fn( nullptr_t np) { }
>>> int main()
>>> {
>>>   char* p =3D nullptr; // I have no desire to break this.
>>>   fp(nullptr); // No desire to break this
>>>   fn(nullptr); // I have no desire to break.
>>>   fn(0); // I'd like to break this. But what else will I break to get
>>> this?
>>>
>>
>> A guiding principle we've been using is that std::nullptr_t acts
>> basically like a pointer type (so that, for instance, you can use it as =
a
>> template argument in a template that wants something like a pointer type=
).
>> For that reason, I suspect there will be opposition to making this
>> ill-formed.
>>
> [...snip...]

What does that mean for this though?:
>
> void f(nullptr_t);
> f(0); // I'd like not to allow this, I think.
>

See above, before [...snip...]. That code remains valid under the current
rules, and there's likely to be opposition to making nullptr_t and pointer
types behave differently here.

Maybe once nullptr gains traction we can consider deprecating the literal
zero as a null pointer constant in general, but I wouldn't expect
deprecation before C++20, and there will probably be enough people who are
over-my-dead-body against that we won't ever manage to deprecate or remove
it.

The good news is that at least GCC already has a warning for using the zero
literal as a null pointer.

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

--047d7b671f3477ae5704f511dc97
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Mar 20, 2014 at 3:08 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 10:29:57 AM UT=
C+13, Richard Smith wrote:<div><div class=3D"h5"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 1:=
27 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">

<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

On 2014-03-19 21:23, <a>gmis...@gmail.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it&#39;s &quot;really&quot; warning about comparison wi=
th &#39;nullptr&#39;. I&#39;m
<br>&gt;&gt; unconvinced that the implicit conversion of &#39;0&#39; to &#3=
9;nullptr&#39; can or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I&#39;m not sure implicit conversion of literal 0 to nullptr i=
s good? Why
<br>&gt; do you think it&#39;s good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that&#39;s the key word: &quot;if&quot;. The amount of code tha=
t would break=20
<br>by doing so is appalling, as *all* pre-C++11 code uses &#39;0&#39; to m=
ean=20
<br>&#39;nullptr&#39;. Thus it is &quot;good&quot; in that it allows pre-C+=
+11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=B9)=
=20
<br>porting.
<br></blockquote></div><div>We don&#39;t know how much code we will break u=
ntil we=A0are=A0sure exactly what kind of statements we&#39;re considering =
breaking.</div><div>I&#39;d find it easier if we talk the simplest statemen=
ts we have problems with, agree on that set=A0than find out what else we&#3=
9;d break.</div>

<div>Agree first what we have problems with, separately from too much argui=
ng over the implications of changing it.</div><div><div><br></div></div><di=
v>I&#39;m not sure if everything I want to see is right or possible but I f=
eel sure some of it is right=A0and possible and that we can=A0improve thing=
s here, even if a little.</div>

<div><br></div><div>What we need is a clear set of simple statements we all=
 can broadly agree are not ideal then see what the impact is of fixing them=
..</div><div>We need example statements. See below.</div><div><div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">
<br>Realistically I don&#39;t see doing any such thing as being feasible fo=
r at=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=B9 e.g. use of &#39;0&#39; as &#39;nullptr&#39; in Qt macros which ca=
n&#39;t be trivially=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-&#39;nullptr&#39;-correct Qt. I&#39;m sure there are other, similar=
 examples;=20
<br>this is one I&#39;m personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, &quot;0&quot; here is implic=
itly converted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only &quot;gotcha&quot; is to make su=
re that the &quot;0&quot;
<br>&gt;&gt; really does convert to &quot;nullptr&quot; and not &quot;(T*)(=
0)&quot;... and, apparently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I&#39;m saying is to not try to interfere with the convers=
ion of &quot;0&quot; to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs =A0sounds like the essence of what I&#39;m mo=
st interested
<br>&gt; in.
<br>
<br>Right; I think we&#39;re on the same page as far as disallowing compari=
son=20
<br>against an effective literal nullptr, we&#39;re just nitpicking whether=
 it=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=B9 If [the compiler, absent a standard change] errored by de=
fault,
<br>&gt;&gt; =A0that would make the compiler non-conforming, which for obvi=
ous
<br>&gt;&gt; reasons I don&#39;t expect the devs to accept. Though I&#39;m =
not sure,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I&#39;m not sellin=
g compilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I&#39;m wrong. (Again, maybe this would be something =
where=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div></div></div><div>It&#39;s hard to talk abou=
t this subject because when you say something it&#39;s easy accidentally or=
 intentionally=A0to say more and less than you mean.</div><div>So I&#39;d l=
ike to start=A0 focus on simple=A0statements=A0to see if we can agree if th=
ey=A0are dubious &quot;as is&quot;, then worry separately what fixing it me=
ans to other statements.</div>

<div>Or how much code it breaks.</div><div>Or how you actually fix it.</div=
><div><br></div><div>Then we can come back and look at it as a whole and na=
rrow it done, give up, or whatever. It makes it simpler to comprehend for p=
eople that aren&#39;t language guru&#39;s.</div>

<div><br></div><div>So here&#39;s some examples:</div><div><br></div><div>#=
include &lt;cstdio&gt; <br>#include &lt;cstddef&gt;<br>using namespace std;=
<br>void fp(char*p) { }<br>void fn( nullptr_t np) { }</div><div>int main()<=
br>

{<br>=A0 char* p =3D nullptr; // I have no desire to break this.</div><div>=
=A0 fp(nullptr); // No desire to break this<br>=A0 fn(nullptr); // I have n=
o desire to break.<br>=A0 fn(0); // I&#39;d like to break this. But what el=
se will I break to get this?<br>

</div></div></blockquote><div><br></div><div>A guiding principle we&#39;ve =
been using is that std::nullptr_t acts basically like a pointer type (so th=
at, for instance, you can use it as a template argument in a template that =
wants something like a pointer type). For that reason, I suspect there will=
 be opposition to making this ill-formed.</div>
</div></div></div></blockquote></div></div></div></blockquote><div>[...snip=
....]</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>
<div class=3D"h5"><div><span style=3D"color:rgb(34,34,34)">What does that m=
ean for this though?:</span><br></div></div></div><div><br></div><div>void =
f(nullptr_t);</div><div>f(0); // I&#39;d like not to allow this, I think.</=
div>
</div></blockquote><div><br></div><div>See above, before [...snip...]. That=
 code remains valid under the current rules, and there&#39;s likely to be o=
pposition to making nullptr_t and pointer types behave differently here.</d=
iv>
<div><br></div><div>Maybe once nullptr gains traction we can consider depre=
cating the literal zero as a null pointer constant in general, but I wouldn=
&#39;t expect deprecation before C++20, and there will probably be enough p=
eople who are over-my-dead-body against that we won&#39;t ever manage to de=
precate or remove it.</div>
<div><br></div><div>The good news is that at least GCC already has a warnin=
g for using the zero literal as a null pointer.</div></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 />

--047d7b671f3477ae5704f511dc97--

.

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

Hi Richard

On Friday, March 21, 2014 12:09:28 PM UTC+13, Richard Smith wrote:
>
> On Thu, Mar 20, 2014 at 3:08 PM, <gmis...@gmail.com <javascript:>> wrote:
>
>> Hi Richard
>>
>> On Friday, March 21, 2014 10:29:57 AM UTC+13, Richard Smith wrote:
>>
>>> On Thu, Mar 20, 2014 at 1:27 PM, <gmis...@gmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>>>>
>>>>> On 2014-03-19 21:23, gmis...@gmail.com wrote:=20
>>>>> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke=20
>>>>> wrote:=20
>>>>> >> ...but it's "really" warning about comparison with 'nullptr'. I'm=
=20
>>>>> >> unconvinced that the implicit conversion of '0' to 'nullptr' can o=
r=20
>>>>> >> should be prevented, even in this case. But...=20
>>>>> >=20
>>>>> > But I'm not sure implicit conversion of literal 0 to nullptr is=20
>>>>> good? Why=20
>>>>> > do you think it's good?=20
>>>>>
>>>>> Honestly? It would probably make for cleaner code if we could=20
>>>>> deprecate=20
>>>>> it. But that's the key word: "if". The amount of code that would brea=
k=20
>>>>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
>>>>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=
=20
>>>>> mixed with C++11 code without major (and sometimes near-impossible=C2=
=B9)=20
>>>>> porting.=20
>>>>>
>>>> We don't know how much code we will break until we are sure exactly=20
>>>> what kind of statements we're considering breaking.
>>>> I'd find it easier if we talk the simplest statements we have problems=
=20
>>>> with, agree on that set than find out what else we'd break.
>>>> Agree first what we have problems with, separately from too much=20
>>>> arguing over the implications of changing it.
>>>>
>>>> I'm not sure if everything I want to see is right or possible but I=20
>>>> feel sure some of it is right and possible and that we can improve thi=
ngs=20
>>>> here, even if a little.
>>>>
>>>> What we need is a clear set of simple statements we all can broadly=20
>>>> agree are not ideal then see what the impact is of fixing them.
>>>> We need example statements. See below.
>>>>
>>>>
>>>>> Realistically I don't see doing any such thing as being feasible for=
=20
>>>>> at=20
>>>>> least ten years... probably more like fifteen to twenty.=20
>>>>>
>>>>> (=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be triv=
ially=20
>>>>> changed by applications that want to use C++11 but build against a=20
>>>>> pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=
=20
>>>>> this is one I'm personally familiar with.)=20
>>>>>
>>>>> >> See previous comments. Right now, "0" here is implicitly converted=
=20
>>>>> to=20
>>>>> >> nullptr. So if we disallow operator< between T* and nullptr_t, we=
=20
>>>>> will=20
>>>>> >> disallow the above. (The only "gotcha" is to make sure that the "0=
"=20
>>>>> >> really does convert to "nullptr" and not "(T*)(0)"... and,=20
>>>>> apparently,=20
>>>>> >> to resolve that currently there is an overload ambiguity here,=20
>>>>> although=20
>>>>> >> given that we want it to be an error, resolving the ambiguity is=
=20
>>>>> rather=20
>>>>> >> superfluous.)=20
>>>>> >>=20
>>>>> >> All I'm saying is to not try to interfere with the conversion of=
=20
>>>>> "0" to=20
>>>>> >> nullptr and/or try to prevent the comparison before that conversio=
n=20
>>>>> >> occurs. (Maybe that was also your intent as well, and I am just=20
>>>>> confused?)=20
>>>>> >=20
>>>>> > These two paragraphs  sounds like the essence of what I'm most=20
>>>>> interested=20
>>>>> > in.=20
>>>>>
>>>>> Right; I think we're on the same page as far as disallowing compariso=
n=20
>>>>> against an effective literal nullptr, we're just nitpicking whether i=
t=20
>>>>> happens before or after implicit conversion of an integer 0 literal t=
o=20
>>>>> nullptr.=20
>>>>>
>>>>> >> (=C2=B9 If [the compiler, absent a standard change] errored by def=
ault,=20
>>>>> >>  that would make the compiler non-conforming, which for obvious=20
>>>>> >> reasons I don't expect the devs to accept. Though I'm not sure,=20
>>>>> >> e.g. see the stuff that -fpermissive allows; maybe this could be a=
=20
>>>>> >> case for that.)=20
>>>>> >=20
>>>>> > Really, this would be that bad?=20
>>>>> > Right is better than conforming to my mind, but I'm not selling=20
>>>>> compilers.=20
>>>>>
>>>>> My knee-jerk reaction is that compiler vendors would rather be=20
>>>>> conforming. Maybe I'm wrong. (Again, maybe this would be something=20
>>>>> where=20
>>>>> e.g. gcc would be okay disallowing it without -fpermissive. Though,=
=20
>>>>> pedantically, the doc says that -fpermissive is for code that is=20
>>>>> sometimes accepted even though it is non-conforming, whereas this is=
=20
>>>>> rather the opposite.)=20
>>>>>
>>>>> Still... I can only give my own impressions. If you want a worthwhile=
=20
>>>>> opinion, take it up with the compiler vendors :-).=20
>>>>>
>>>>> --=20
>>>>> Matthew=20
>>>>>
>>>>>
>>>> It's hard to talk about this subject because when you say something=20
>>>> it's easy accidentally or intentionally to say more and less than you =
mean.
>>>> So I'd like to start  focus on simple statements to see if we can agre=
e=20
>>>> if they are dubious "as is", then worry separately what fixing it mean=
s to=20
>>>> other statements.
>>>> Or how much code it breaks.
>>>> Or how you actually fix it.
>>>>
>>>> Then we can come back and look at it as a whole and narrow it done,=20
>>>> give up, or whatever. It makes it simpler to comprehend for people tha=
t=20
>>>> aren't language guru's.
>>>>
>>>> So here's some examples:
>>>>
>>>> #include <cstdio>=20
>>>> #include <cstddef>
>>>> using namespace std;
>>>> void fp(char*p) { }
>>>> void fn( nullptr_t np) { }
>>>> int main()
>>>> {
>>>>   char* p =3D nullptr; // I have no desire to break this.
>>>>   fp(nullptr); // No desire to break this
>>>>   fn(nullptr); // I have no desire to break.
>>>>   fn(0); // I'd like to break this. But what else will I break to get=
=20
>>>> this?
>>>>
>>>
>>> A guiding principle we've been using is that std::nullptr_t acts=20
>>> basically like a pointer type (so that, for instance, you can use it as=
 a=20
>>> template argument in a template that wants something like a pointer typ=
e).=20
>>> For that reason, I suspect there will be opposition to making this=20
>>> ill-formed.
>>>
>> [...snip...]
>
> What does that mean for this though?:
>>
>> void f(nullptr_t);
>> f(0); // I'd like not to allow this, I think.
>>
>
> See above, before [...snip...]. That code remains valid under the current=
=20
> rules, and there's likely to be opposition to making nullptr_t and pointe=
r=20
> types behave differently here.
>

Can you give me a 1 or 2 line max example of what kind of code would break=
=20
other than the above example of preventing 0 converting to nullptr_t=20
implicitly?

I'm just trying to understand why someone needs to implicitly convert 0 to=
=20
nullptr_t and therefore why they'd object to removing that.

Maybe once nullptr gains traction we can consider deprecating the literal=
=20
> zero as a null pointer constant in general, but I wouldn't expect=20
> deprecation before C++20, and there will probably be enough people who ar=
e=20
> over-my-dead-body against that we won't ever manage to deprecate or remov=
e=20
> it.
>
> The good news is that at least GCC already has a warning for using the=20
> zero literal as a null pointer.
>

To be clear:
I understand that this has to work
f( char* );
f(0); // I get that this wants to be f(nullptr) but we can't enforce that=
=20
yet for compatibility.
// conversion tools to the rescue for this.

But I don't understand why:
f(nullptr_t);
f(0);
has to work unless it's related to making the first example work?

I'm sure the answer to this must be obvious to the potential objectors=20
you mention, but it's unfortunately not clear to me yet what the objection=
=20
would be. If anyone objects, I'm keen to hear that to help my understanding=
=20
of the situation.

Thanks

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

<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 12:09:28 PM UT=
C+13, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 3:08 PM,  <span dir=3D=
"ltr">&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"9YV4bzDaYrcJ">gmis...@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 10:29:57 AM UT=
C+13, Richard Smith wrote:<div><div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 1:=
27 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;">

<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">

On 2014-03-19 21:23, <a>gmis...@gmail.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it's "really" warning about comparison with 'nullptr'. =
I'm
<br>&gt;&gt; unconvinced that the implicit conversion of '0' to 'nullptr' c=
an or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I'm not sure implicit conversion of literal 0 to nullptr is go=
od? Why
<br>&gt; do you think it's good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that's the key word: "if". The amount of code that would break=
=20
<br>by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
<br>'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=C2=
=B9)=20
<br>porting.
<br></blockquote></div><div>We don't know how much code we will break until=
 we&nbsp;are&nbsp;sure exactly what kind of statements we're considering br=
eaking.</div><div>I'd find it easier if we talk the simplest statements we =
have problems with, agree on that set&nbsp;than find out what else we'd bre=
ak.</div>

<div>Agree first what we have problems with, separately from too much argui=
ng over the implications of changing it.</div><div><div><br></div></div><di=
v>I'm not sure if everything I want to see is right or possible but I feel =
sure some of it is right&nbsp;and possible and that we can&nbsp;improve thi=
ngs here, even if a little.</div>

<div><br></div><div>What we need is a clear set of simple statements we all=
 can broadly agree are not ideal then see what the impact is of fixing them=
..</div><div>We need example statements. See below.</div><div><div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">
<br>Realistically I don't see doing any such thing as being feasible for at=
=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivia=
lly=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=
=20
<br>this is one I'm personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, "0" here is implicitly conve=
rted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only "gotcha" is to make sure that th=
e "0"
<br>&gt;&gt; really does convert to "nullptr" and not "(T*)(0)"... and, app=
arently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I'm saying is to not try to interfere with the conversion =
of "0" to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs &nbsp;sounds like the essence of what I'm mos=
t interested
<br>&gt; in.
<br>
<br>Right; I think we're on the same page as far as disallowing comparison=
=20
<br>against an effective literal nullptr, we're just nitpicking whether it=
=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=C2=B9 If [the compiler, absent a standard change] errored by=
 default,
<br>&gt;&gt; &nbsp;that would make the compiler non-conforming, which for o=
bvious
<br>&gt;&gt; reasons I don't expect the devs to accept. Though I'm not sure=
,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I'm not selling co=
mpilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I'm wrong. (Again, maybe this would be something wher=
e=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div></div></div><div>It's hard to talk about th=
is subject because when you say something it's easy accidentally or intenti=
onally&nbsp;to say more and less than you mean.</div><div>So I'd like to st=
art&nbsp; focus on simple&nbsp;statements&nbsp;to see if we can agree if th=
ey&nbsp;are dubious "as is", then worry separately what fixing it means to =
other statements.</div>

<div>Or how much code it breaks.</div><div>Or how you actually fix it.</div=
><div><br></div><div>Then we can come back and look at it as a whole and na=
rrow it done, give up, or whatever. It makes it simpler to comprehend for p=
eople that aren't language guru's.</div>

<div><br></div><div>So here's some examples:</div><div><br></div><div>#incl=
ude &lt;cstdio&gt; <br>#include &lt;cstddef&gt;<br>using namespace std;<br>=
void fp(char*p) { }<br>void fn( nullptr_t np) { }</div><div>int main()<br>

{<br>&nbsp; char* p =3D nullptr; // I have no desire to break this.</div><d=
iv>&nbsp; fp(nullptr); // No desire to break this<br>&nbsp; fn(nullptr); //=
 I have no desire to break.<br>&nbsp; fn(0); // I'd like to break this. But=
 what else will I break to get this?<br>

</div></div></blockquote><div><br></div><div>A guiding principle we've been=
 using is that std::nullptr_t acts basically like a pointer type (so that, =
for instance, you can use it as a template argument in a template that want=
s something like a pointer type). For that reason, I suspect there will be =
opposition to making this ill-formed.</div>
</div></div></div></blockquote></div></div></div></blockquote><div>[...snip=
....]</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div=
>
<div><div><span style=3D"color: rgb(34, 34, 34);">What does that mean for t=
his though?:</span><br></div></div></div><div><br></div><div>void f(nullptr=
_t);</div><div>f(0); // I'd like not to allow this, I think.</div>
</div></blockquote><div><br></div><div>See above, before [...snip...]. That=
 code remains valid under the current rules, and there's likely to be oppos=
ition to making nullptr_t and pointer types behave differently here.</div><=
/div></div></div></blockquote><div><br></div><div>Can you give me a 1 or 2 =
line max example of what kind of&nbsp;code would break other than the above=
 example of preventing 0 converting to nullptr_t implicitly?</div><div><br>=
</div><div>I'm just trying to understand why someone needs&nbsp;to implicit=
ly convert 0 to nullptr_t and therefore why they'd object to removing that.=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div>Maybe once nullptr gains traction we can consi=
der deprecating the literal zero as a null pointer constant in general, but=
 I wouldn't expect deprecation before C++20, and there will probably be eno=
ugh people who are over-my-dead-body against that we won't ever manage to d=
eprecate or remove it.</div>
<div><br></div><div>The good news is that at least GCC already has a warnin=
g for using the zero literal as a null pointer.</div></div></div></div></bl=
ockquote><div><br></div><div>To be clear:</div><div>I understand that this =
has to work</div><div>f( char* );</div><div>f(0);&nbsp;// I get that this w=
ants to be&nbsp;f(nullptr) but we can't enforce that yet for compatibility.=
</div><div>// conversion tools to the rescue for this.</div><div><br></div>=
<div>But I don't understand why:</div><div>f(nullptr_t);</div><div>f(0);</d=
iv><div>has to work unless it's related to making&nbsp;the&nbsp;first examp=
le&nbsp;work?</div><div><br></div><div>I'm sure the answer to this&nbsp;mus=
t be&nbsp;obvious&nbsp;to&nbsp;the potential&nbsp;objectors you&nbsp;mentio=
n, but it's&nbsp;unfortunately not clear to me yet what the objection would=
 be. If anyone objects, I'm keen to hear that to help my understanding of t=
he situation.</div><div><br></div><div>Thanks</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_37_14068532.1395448438129--

.

--001a1136563821744604f52833ea
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2014 at 5:33 PM, <gmisocpp@gmail.com> wrote:

> Hi Richard
>
> On Friday, March 21, 2014 12:09:28 PM UTC+13, Richard Smith wrote:
>
>> On Thu, Mar 20, 2014 at 3:08 PM, <gmis...@gmail.com> wrote:
>>
>>> Hi Richard
>>>
>>> On Friday, March 21, 2014 10:29:57 AM UTC+13, Richard Smith wrote:
>>>
>>>> On Thu, Mar 20, 2014 at 1:27 PM, <gmis...@gmail.com> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>>>>>
>>>>>> On 2014-03-19 21:23, gmis...@gmail.com wrote:
>>>>>> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke
>>>>>> wrote:
>>>>>> >> ...but it's "really" warning about comparison with 'nullptr'. I'm
>>>>>> >> unconvinced that the implicit conversion of '0' to 'nullptr' can
>>>>>> or
>>>>>> >> should be prevented, even in this case. But...
>>>>>> >
>>>>>> > But I'm not sure implicit conversion of literal 0 to nullptr is
>>>>>> good? Why
>>>>>> > do you think it's good?
>>>>>>
>>>>>> Honestly? It would probably make for cleaner code if we could
>>>>>> deprecate
>>>>>> it. But that's the key word: "if". The amount of code that would
>>>>>> break
>>>>>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean
>>>>>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be
>>>>>> mixed with C++11 code without major (and sometimes near-impossible=
=B9)
>>>>>> porting.
>>>>>>
>>>>> We don't know how much code we will break until we are sure exactly
>>>>> what kind of statements we're considering breaking.
>>>>> I'd find it easier if we talk the simplest statements we have problem=
s
>>>>> with, agree on that set than find out what else we'd break.
>>>>> Agree first what we have problems with, separately from too much
>>>>> arguing over the implications of changing it.
>>>>>
>>>>> I'm not sure if everything I want to see is right or possible but I
>>>>> feel sure some of it is right and possible and that we can improve th=
ings
>>>>> here, even if a little.
>>>>>
>>>>> What we need is a clear set of simple statements we all can broadly
>>>>> agree are not ideal then see what the impact is of fixing them.
>>>>> We need example statements. See below.
>>>>>
>>>>>
>>>>>> Realistically I don't see doing any such thing as being feasible for
>>>>>> at
>>>>>> least ten years... probably more like fifteen to twenty.
>>>>>>
>>>>>> (=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivia=
lly
>>>>>> changed by applications that want to use C++11 but build against a
>>>>>> pre-'nullptr'-correct Qt. I'm sure there are other, similar examples=
;
>>>>>> this is one I'm personally familiar with.)
>>>>>>
>>>>>> >> See previous comments. Right now, "0" here is implicitly converte=
d
>>>>>> to
>>>>>> >> nullptr. So if we disallow operator< between T* and nullptr_t, we
>>>>>> will
>>>>>> >> disallow the above. (The only "gotcha" is to make sure that the
>>>>>> "0"
>>>>>> >> really does convert to "nullptr" and not "(T*)(0)"... and,
>>>>>> apparently,
>>>>>> >> to resolve that currently there is an overload ambiguity here,
>>>>>> although
>>>>>> >> given that we want it to be an error, resolving the ambiguity is
>>>>>> rather
>>>>>> >> superfluous.)
>>>>>> >>
>>>>>> >> All I'm saying is to not try to interfere with the conversion of
>>>>>> "0" to
>>>>>> >> nullptr and/or try to prevent the comparison before that
>>>>>> conversion
>>>>>> >> occurs. (Maybe that was also your intent as well, and I am just
>>>>>> confused?)
>>>>>> >
>>>>>> > These two paragraphs  sounds like the essence of what I'm most
>>>>>> interested
>>>>>> > in.
>>>>>>
>>>>>> Right; I think we're on the same page as far as disallowing
>>>>>> comparison
>>>>>> against an effective literal nullptr, we're just nitpicking whether
>>>>>> it
>>>>>> happens before or after implicit conversion of an integer 0 literal
>>>>>> to
>>>>>> nullptr.
>>>>>>
>>>>>> >> (=B9 If [the compiler, absent a standard change] errored by defau=
lt,
>>>>>> >>  that would make the compiler non-conforming, which for obvious
>>>>>> >> reasons I don't expect the devs to accept. Though I'm not sure,
>>>>>> >> e.g. see the stuff that -fpermissive allows; maybe this could be =
a
>>>>>> >> case for that.)
>>>>>> >
>>>>>> > Really, this would be that bad?
>>>>>> > Right is better than conforming to my mind, but I'm not selling
>>>>>> compilers.
>>>>>>
>>>>>> My knee-jerk reaction is that compiler vendors would rather be
>>>>>> conforming. Maybe I'm wrong. (Again, maybe this would be something
>>>>>> where
>>>>>> e.g. gcc would be okay disallowing it without -fpermissive. Though,
>>>>>> pedantically, the doc says that -fpermissive is for code that is
>>>>>> sometimes accepted even though it is non-conforming, whereas this is
>>>>>> rather the opposite.)
>>>>>>
>>>>>> Still... I can only give my own impressions. If you want a worthwhil=
e
>>>>>> opinion, take it up with the compiler vendors :-).
>>>>>>
>>>>>> --
>>>>>> Matthew
>>>>>>
>>>>>>
>>>>> It's hard to talk about this subject because when you say something
>>>>> it's easy accidentally or intentionally to say more and less than you=
 mean.
>>>>> So I'd like to start  focus on simple statements to see if we can
>>>>> agree if they are dubious "as is", then worry separately what fixing =
it
>>>>> means to other statements.
>>>>> Or how much code it breaks.
>>>>> Or how you actually fix it.
>>>>>
>>>>> Then we can come back and look at it as a whole and narrow it done,
>>>>> give up, or whatever. It makes it simpler to comprehend for people th=
at
>>>>> aren't language guru's.
>>>>>
>>>>> So here's some examples:
>>>>>
>>>>> #include <cstdio>
>>>>> #include <cstddef>
>>>>> using namespace std;
>>>>> void fp(char*p) { }
>>>>> void fn( nullptr_t np) { }
>>>>> int main()
>>>>> {
>>>>>   char* p =3D nullptr; // I have no desire to break this.
>>>>>   fp(nullptr); // No desire to break this
>>>>>   fn(nullptr); // I have no desire to break.
>>>>>   fn(0); // I'd like to break this. But what else will I break to get
>>>>> this?
>>>>>
>>>>
>>>> A guiding principle we've been using is that std::nullptr_t acts
>>>> basically like a pointer type (so that, for instance, you can use it a=
s a
>>>> template argument in a template that wants something like a pointer ty=
pe).
>>>> For that reason, I suspect there will be opposition to making this
>>>> ill-formed.
>>>>
>>> [...snip...]
>>
>> What does that mean for this though?:
>>>
>>> void f(nullptr_t);
>>> f(0); // I'd like not to allow this, I think.
>>>
>>
>> See above, before [...snip...]. That code remains valid under the curren=
t
>> rules, and there's likely to be opposition to making nullptr_t and point=
er
>> types behave differently here.
>>
>
> Can you give me a 1 or 2 line max example of what kind of code would brea=
k
> other than the above example of preventing 0 converting to nullptr_t
> implicitly?
>
> I'm just trying to understand why someone needs to implicitly convert 0 t=
o
> nullptr_t and therefore why they'd object to removing that.
>
> Maybe once nullptr gains traction we can consider deprecating the literal
>> zero as a null pointer constant in general, but I wouldn't expect
>> deprecation before C++20, and there will probably be enough people who a=
re
>> over-my-dead-body against that we won't ever manage to deprecate or remo=
ve
>> it.
>>
>> The good news is that at least GCC already has a warning for using the
>> zero literal as a null pointer.
>>
>
> To be clear:
> I understand that this has to work
> f( char* );
> f(0); // I get that this wants to be f(nullptr) but we can't enforce that
> yet for compatibility.
> // conversion tools to the rescue for this.
>
> But I don't understand why:
> f(nullptr_t);
> f(0);
> has to work unless it's related to making the first example work?
>
> I'm sure the answer to this must be obvious to the potential objectors
> you mention, but it's unfortunately not clear to me yet what the objectio=
n
> would be. If anyone objects, I'm keen to hear that to help my understandi=
ng
> of the situation.
>

See:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#654

The argument that resulted in the current rules is presented there.

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

--001a1136563821744604f52833ea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 21, 2014 at 5:33 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 12:09:28 PM UT=
C+13, Richard Smith wrote:<div><div class=3D"h5"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 3:=
08 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">

<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 10:29:57 AM UT=
C+13, Richard Smith wrote:<div><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 1:=
27 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">


<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">


On 2014-03-19 21:23, <a>gmis...@gmail.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it&#39;s &quot;really&quot; warning about comparison wi=
th &#39;nullptr&#39;. I&#39;m
<br>&gt;&gt; unconvinced that the implicit conversion of &#39;0&#39; to &#3=
9;nullptr&#39; can or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I&#39;m not sure implicit conversion of literal 0 to nullptr i=
s good? Why
<br>&gt; do you think it&#39;s good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that&#39;s the key word: &quot;if&quot;. The amount of code tha=
t would break=20
<br>by doing so is appalling, as *all* pre-C++11 code uses &#39;0&#39; to m=
ean=20
<br>&#39;nullptr&#39;. Thus it is &quot;good&quot; in that it allows pre-C+=
+11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=B9)=
=20
<br>porting.
<br></blockquote></div><div>We don&#39;t know how much code we will break u=
ntil we=A0are=A0sure exactly what kind of statements we&#39;re considering =
breaking.</div><div>I&#39;d find it easier if we talk the simplest statemen=
ts we have problems with, agree on that set=A0than find out what else we&#3=
9;d break.</div>


<div>Agree first what we have problems with, separately from too much argui=
ng over the implications of changing it.</div><div><div><br></div></div><di=
v>I&#39;m not sure if everything I want to see is right or possible but I f=
eel sure some of it is right=A0and possible and that we can=A0improve thing=
s here, even if a little.</div>


<div><br></div><div>What we need is a clear set of simple statements we all=
 can broadly agree are not ideal then see what the impact is of fixing them=
..</div><div>We need example statements. See below.</div><div><div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">
<br>Realistically I don&#39;t see doing any such thing as being feasible fo=
r at=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=B9 e.g. use of &#39;0&#39; as &#39;nullptr&#39; in Qt macros which ca=
n&#39;t be trivially=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-&#39;nullptr&#39;-correct Qt. I&#39;m sure there are other, similar=
 examples;=20
<br>this is one I&#39;m personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, &quot;0&quot; here is implic=
itly converted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only &quot;gotcha&quot; is to make su=
re that the &quot;0&quot;
<br>&gt;&gt; really does convert to &quot;nullptr&quot; and not &quot;(T*)(=
0)&quot;... and, apparently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I&#39;m saying is to not try to interfere with the convers=
ion of &quot;0&quot; to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs =A0sounds like the essence of what I&#39;m mo=
st interested
<br>&gt; in.
<br>
<br>Right; I think we&#39;re on the same page as far as disallowing compari=
son=20
<br>against an effective literal nullptr, we&#39;re just nitpicking whether=
 it=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=B9 If [the compiler, absent a standard change] errored by de=
fault,
<br>&gt;&gt; =A0that would make the compiler non-conforming, which for obvi=
ous
<br>&gt;&gt; reasons I don&#39;t expect the devs to accept. Though I&#39;m =
not sure,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I&#39;m not sellin=
g compilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I&#39;m wrong. (Again, maybe this would be something =
where=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div></div></div><div>It&#39;s hard to talk abou=
t this subject because when you say something it&#39;s easy accidentally or=
 intentionally=A0to say more and less than you mean.</div><div>So I&#39;d l=
ike to start=A0 focus on simple=A0statements=A0to see if we can agree if th=
ey=A0are dubious &quot;as is&quot;, then worry separately what fixing it me=
ans to other statements.</div>


<div>Or how much code it breaks.</div><div>Or how you actually fix it.</div=
><div><br></div><div>Then we can come back and look at it as a whole and na=
rrow it done, give up, or whatever. It makes it simpler to comprehend for p=
eople that aren&#39;t language guru&#39;s.</div>


<div><br></div><div>So here&#39;s some examples:</div><div><br></div><div>#=
include &lt;cstdio&gt; <br>#include &lt;cstddef&gt;<br>using namespace std;=
<br>void fp(char*p) { }<br>void fn( nullptr_t np) { }</div><div>int main()<=
br>


{<br>=A0 char* p =3D nullptr; // I have no desire to break this.</div><div>=
=A0 fp(nullptr); // No desire to break this<br>=A0 fn(nullptr); // I have n=
o desire to break.<br>=A0 fn(0); // I&#39;d like to break this. But what el=
se will I break to get this?<br>


</div></div></blockquote><div><br></div><div>A guiding principle we&#39;ve =
been using is that std::nullptr_t acts basically like a pointer type (so th=
at, for instance, you can use it as a template argument in a template that =
wants something like a pointer type). For that reason, I suspect there will=
 be opposition to making this ill-formed.</div>

</div></div></div></blockquote></div></div></div></blockquote><div>[...snip=
....]</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>
<div><div><span style=3D"color:rgb(34,34,34)">What does that mean for this =
though?:</span><br></div></div></div><div><br></div><div>void f(nullptr_t);=
</div><div>f(0); // I&#39;d like not to allow this, I think.</div>
</div></blockquote><div><br></div><div>See above, before [...snip...]. That=
 code remains valid under the current rules, and there&#39;s likely to be o=
pposition to making nullptr_t and pointer types behave differently here.</d=
iv>
</div></div></div></blockquote><div><br></div></div></div><div>Can you give=
 me a 1 or 2 line max example of what kind of=A0code would break other than=
 the above example of preventing 0 converting to nullptr_t implicitly?</div=
>
<div><br></div><div>I&#39;m just trying to understand why someone needs=A0t=
o implicitly convert 0 to nullptr_t and therefore why they&#39;d object to =
removing that.</div><div class=3D""><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-co=
lor:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Maybe once nullptr ga=
ins traction we can consider deprecating the literal zero as a null pointer=
 constant in general, but I wouldn&#39;t expect deprecation before C++20, a=
nd there will probably be enough people who are over-my-dead-body against t=
hat we won&#39;t ever manage to deprecate or remove it.</div>

<div><br></div><div>The good news is that at least GCC already has a warnin=
g for using the zero literal as a null pointer.</div></div></div></div></bl=
ockquote><div><br></div></div><div>To be clear:</div><div>I understand that=
 this has to work</div>
<div>f( char* );</div><div>f(0);=A0// I get that this wants to be=A0f(nullp=
tr) but we can&#39;t enforce that yet for compatibility.</div><div>// conve=
rsion tools to the rescue for this.</div><div><br></div><div>But I don&#39;=
t understand why:</div>
<div>f(nullptr_t);</div><div>f(0);</div><div>has to work unless it&#39;s re=
lated to making=A0the=A0first example=A0work?</div><div><br></div><div>I&#3=
9;m sure the answer to this=A0must be=A0obvious=A0to=A0the potential=A0obje=
ctors you=A0mention, but it&#39;s=A0unfortunately not clear to me yet what =
the objection would be. If anyone objects, I&#39;m keen to hear that to hel=
p my understanding of the situation.</div>
</div></blockquote><div><br></div><div>See:</div><div><br></div><div><a hre=
f=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#654">http=
://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#654</a></div><div>
<br></div><div>The argument that resulted in the current rules is presented=
 there.</div></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 />

--001a1136563821744604f52833ea--

.

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

Hi Richard

On Saturday, March 22, 2014 2:48:32 PM UTC+13, Richard Smith wrote:
>
> On Fri, Mar 21, 2014 at 5:33 PM, <gmis...@gmail.com <javascript:>> wrote:
>
>> Hi Richard
>>
>> On Friday, March 21, 2014 12:09:28 PM UTC+13, Richard Smith wrote:
>>
>>> On Thu, Mar 20, 2014 at 3:08 PM, <gmis...@gmail.com> wrote:
>>>
>>>> Hi Richard
>>>>
>>>> On Friday, March 21, 2014 10:29:57 AM UTC+13, Richard Smith wrote:
>>>>
>>>>> On Thu, Mar 20, 2014 at 1:27 PM, <gmis...@gmail.com> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>>>>>>
>>>>>>> On 2014-03-19 21:23, gmis...@gmail.com wrote:=20
>>>>>>> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke=
=20
>>>>>>> wrote:=20
>>>>>>> >> ...but it's "really" warning about comparison with 'nullptr'. I'=
m=20
>>>>>>> >> unconvinced that the implicit conversion of '0' to 'nullptr' can=
=20
>>>>>>> or=20
>>>>>>> >> should be prevented, even in this case. But...=20
>>>>>>> >=20
>>>>>>> > But I'm not sure implicit conversion of literal 0 to nullptr is=
=20
>>>>>>> good? Why=20
>>>>>>> > do you think it's good?=20
>>>>>>>
>>>>>>> Honestly? It would probably make for cleaner code if we could=20
>>>>>>> deprecate=20
>>>>>>> it. But that's the key word: "if". The amount of code that would=20
>>>>>>> break=20
>>>>>>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=
=20
>>>>>>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=
=20
>>>>>>> mixed with C++11 code without major (and sometimes near-impossible=
=C2=B9)=20
>>>>>>> porting.=20
>>>>>>>
>>>>>> We don't know how much code we will break until we are sure exactly=
=20
>>>>>> what kind of statements we're considering breaking.
>>>>>> I'd find it easier if we talk the simplest statements we have=20
>>>>>> problems with, agree on that set than find out what else we'd break.
>>>>>> Agree first what we have problems with, separately from too much=20
>>>>>> arguing over the implications of changing it.
>>>>>>
>>>>>> I'm not sure if everything I want to see is right or possible but I=
=20
>>>>>> feel sure some of it is right and possible and that we can improve t=
hings=20
>>>>>> here, even if a little.
>>>>>>
>>>>>> What we need is a clear set of simple statements we all can broadly=
=20
>>>>>> agree are not ideal then see what the impact is of fixing them.
>>>>>> We need example statements. See below.
>>>>>>
>>>>>>
>>>>>>> Realistically I don't see doing any such thing as being feasible fo=
r=20
>>>>>>> at=20
>>>>>>> least ten years... probably more like fifteen to twenty.=20
>>>>>>>
>>>>>>> (=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be=20
>>>>>>> trivially=20
>>>>>>> changed by applications that want to use C++11 but build against a=
=20
>>>>>>> pre-'nullptr'-correct Qt. I'm sure there are other, similar=20
>>>>>>> examples;=20
>>>>>>> this is one I'm personally familiar with.)=20
>>>>>>>
>>>>>>> >> See previous comments. Right now, "0" here is implicitly=20
>>>>>>> converted to=20
>>>>>>> >> nullptr. So if we disallow operator< between T* and nullptr_t, w=
e=20
>>>>>>> will=20
>>>>>>> >> disallow the above. (The only "gotcha" is to make sure that the=
=20
>>>>>>> "0"=20
>>>>>>> >> really does convert to "nullptr" and not "(T*)(0)"... and,=20
>>>>>>> apparently,=20
>>>>>>> >> to resolve that currently there is an overload ambiguity here,=
=20
>>>>>>> although=20
>>>>>>> >> given that we want it to be an error, resolving the ambiguity is=
=20
>>>>>>> rather=20
>>>>>>> >> superfluous.)=20
>>>>>>> >>=20
>>>>>>> >> All I'm saying is to not try to interfere with the conversion of=
=20
>>>>>>> "0" to=20
>>>>>>> >> nullptr and/or try to prevent the comparison before that=20
>>>>>>> conversion=20
>>>>>>> >> occurs. (Maybe that was also your intent as well, and I am just=
=20
>>>>>>> confused?)=20
>>>>>>> >=20
>>>>>>> > These two paragraphs  sounds like the essence of what I'm most=20
>>>>>>> interested=20
>>>>>>> > in.=20
>>>>>>>
>>>>>>> Right; I think we're on the same page as far as disallowing=20
>>>>>>> comparison=20
>>>>>>> against an effective literal nullptr, we're just nitpicking whether=
=20
>>>>>>> it=20
>>>>>>> happens before or after implicit conversion of an integer 0 literal=
=20
>>>>>>> to=20
>>>>>>> nullptr.=20
>>>>>>>
>>>>>>> >> (=C2=B9 If [the compiler, absent a standard change] errored by=
=20
>>>>>>> default,=20
>>>>>>> >>  that would make the compiler non-conforming, which for obvious=
=20
>>>>>>> >> reasons I don't expect the devs to accept. Though I'm not sure,=
=20
>>>>>>> >> e.g. see the stuff that -fpermissive allows; maybe this could be=
=20
>>>>>>> a=20
>>>>>>> >> case for that.)=20
>>>>>>> >=20
>>>>>>> > Really, this would be that bad?=20
>>>>>>> > Right is better than conforming to my mind, but I'm not selling=
=20
>>>>>>> compilers.=20
>>>>>>>
>>>>>>> My knee-jerk reaction is that compiler vendors would rather be=20
>>>>>>> conforming. Maybe I'm wrong. (Again, maybe this would be something=
=20
>>>>>>> where=20
>>>>>>> e.g. gcc would be okay disallowing it without -fpermissive. Though,=
=20
>>>>>>> pedantically, the doc says that -fpermissive is for code that is=20
>>>>>>> sometimes accepted even though it is non-conforming, whereas this i=
s=20
>>>>>>> rather the opposite.)=20
>>>>>>>
>>>>>>> Still... I can only give my own impressions. If you want a=20
>>>>>>> worthwhile=20
>>>>>>> opinion, take it up with the compiler vendors :-).=20
>>>>>>>
>>>>>>> --=20
>>>>>>> Matthew=20
>>>>>>>
>>>>>>>
>>>>>> It's hard to talk about this subject because when you say something=
=20
>>>>>> it's easy accidentally or intentionally to say more and less than yo=
u mean.
>>>>>> So I'd like to start  focus on simple statements to see if we can=20
>>>>>> agree if they are dubious "as is", then worry separately what fixing=
 it=20
>>>>>> means to other statements.
>>>>>> Or how much code it breaks.
>>>>>> Or how you actually fix it.
>>>>>>
>>>>>> Then we can come back and look at it as a whole and narrow it done,=
=20
>>>>>> give up, or whatever. It makes it simpler to comprehend for people t=
hat=20
>>>>>> aren't language guru's.
>>>>>>
>>>>>> So here's some examples:
>>>>>>
>>>>>> #include <cstdio>=20
>>>>>> #include <cstddef>
>>>>>> using namespace std;
>>>>>> void fp(char*p) { }
>>>>>> void fn( nullptr_t np) { }
>>>>>> int main()
>>>>>> {
>>>>>>   char* p =3D nullptr; // I have no desire to break this.
>>>>>>   fp(nullptr); // No desire to break this
>>>>>>   fn(nullptr); // I have no desire to break.
>>>>>>   fn(0); // I'd like to break this. But what else will I break to ge=
t=20
>>>>>> this?
>>>>>>
>>>>>
>>>>> A guiding principle we've been using is that std::nullptr_t acts=20
>>>>> basically like a pointer type (so that, for instance, you can use it =
as a=20
>>>>> template argument in a template that wants something like a pointer t=
ype).=20
>>>>> For that reason, I suspect there will be opposition to making this=20
>>>>> ill-formed.
>>>>>
>>>> [...snip...]
>>>
>>>  What does that mean for this though?:
>>>>
>>>> void f(nullptr_t);
>>>> f(0); // I'd like not to allow this, I think.
>>>>
>>>
>>> See above, before [...snip...]. That code remains valid under the=20
>>> current rules, and there's likely to be opposition to making nullptr_t =
and=20
>>> pointer types behave differently here.
>>>
>>
>> Can you give me a 1 or 2 line max example of what kind of code would=20
>> break other than the above example of preventing 0 converting to nullptr=
_t=20
>> implicitly?
>>
>> I'm just trying to understand why someone needs to implicitly convert 0=
=20
>> to nullptr_t and therefore why they'd object to removing that.
>>
>> Maybe once nullptr gains traction we can consider deprecating the litera=
l=20
>>> zero as a null pointer constant in general, but I wouldn't expect=20
>>> deprecation before C++20, and there will probably be enough people who =
are=20
>>> over-my-dead-body against that we won't ever manage to deprecate or rem=
ove=20
>>> it.
>>>
>>> The good news is that at least GCC already has a warning for using the=
=20
>>> zero literal as a null pointer.
>>>
>>
>> To be clear:
>> I understand that this has to work
>> f( char* );
>> f(0); // I get that this wants to be f(nullptr) but we can't enforce tha=
t=20
>> yet for compatibility.
>> // conversion tools to the rescue for this.
>>
>> But I don't understand why:
>> f(nullptr_t);
>> f(0);
>> has to work unless it's related to making the first example work?
>>
>> I'm sure the answer to this must be obvious to the potential objectors=
=20
>> you mention, but it's unfortunately not clear to me yet what the objecti=
on=20
>> would be. If anyone objects, I'm keen to hear that to help my understand=
ing=20
>> of the situation.
>>
>
> See:
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#654<http://w=
ww.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F=
docs%2Fcwg_defects.html%23654&sa=3DD&sntz=3D1&usg=3DAFQjCNHnR-KXCcnRCaf7yhS=
Jh4ToVVz9LA>
>
> The argument that resulted in the current rules is presented there.
>

Having read the arguments, I didn't find them completely compelling. But=20
may I didn't fully understand them or the implications of them.

These two examples, if taken literally:

    if (nullptr) ;      // evaluates to false
    if( nullptr =3D=3D 0 ); // evaluates to true


Who would write such statements as is?

I don't see it compelling to allow =3D=3D 0 with smart pointers either.

It seems like an attempt to allow the continued dubious practice of using 0=
=20
with pointers.
Or enabling new features to be (ab)used with old style.

Something tells me I'm missing something obvious here.

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

<div dir=3D"ltr">Hi Richard<br><br>On Saturday, March 22, 2014 2:48:32 PM U=
TC+13, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote">On Fri, Mar 21, 2014 at 5:33 PM,  <span dir=
=3D"ltr">&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"Y7uIYiFkN84J">gmis...@gmail.com</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 12:09:28 PM UT=
C+13, Richard Smith wrote:<div><div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 3:=
08 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;">

<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 10:29:57 AM UT=
C+13, Richard Smith wrote:<div><div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">

<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 1:=
27 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;">


<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;">


On 2014-03-19 21:23, <a>gmis...@gmail.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it's "really" warning about comparison with 'nullptr'. =
I'm
<br>&gt;&gt; unconvinced that the implicit conversion of '0' to 'nullptr' c=
an or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I'm not sure implicit conversion of literal 0 to nullptr is go=
od? Why
<br>&gt; do you think it's good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that's the key word: "if". The amount of code that would break=
=20
<br>by doing so is appalling, as *all* pre-C++11 code uses '0' to mean=20
<br>'nullptr'. Thus it is "good" in that it allows pre-C++11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=C2=
=B9)=20
<br>porting.
<br></blockquote></div><div>We don't know how much code we will break until=
 we&nbsp;are&nbsp;sure exactly what kind of statements we're considering br=
eaking.</div><div>I'd find it easier if we talk the simplest statements we =
have problems with, agree on that set&nbsp;than find out what else we'd bre=
ak.</div>


<div>Agree first what we have problems with, separately from too much argui=
ng over the implications of changing it.</div><div><div><br></div></div><di=
v>I'm not sure if everything I want to see is right or possible but I feel =
sure some of it is right&nbsp;and possible and that we can&nbsp;improve thi=
ngs here, even if a little.</div>


<div><br></div><div>What we need is a clear set of simple statements we all=
 can broadly agree are not ideal then see what the impact is of fixing them=
..</div><div>We need example statements. See below.</div><div><div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;">
<br>Realistically I don't see doing any such thing as being feasible for at=
=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=C2=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be trivia=
lly=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-'nullptr'-correct Qt. I'm sure there are other, similar examples;=
=20
<br>this is one I'm personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, "0" here is implicitly conve=
rted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only "gotcha" is to make sure that th=
e "0"
<br>&gt;&gt; really does convert to "nullptr" and not "(T*)(0)"... and, app=
arently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I'm saying is to not try to interfere with the conversion =
of "0" to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs &nbsp;sounds like the essence of what I'm mos=
t interested
<br>&gt; in.
<br>
<br>Right; I think we're on the same page as far as disallowing comparison=
=20
<br>against an effective literal nullptr, we're just nitpicking whether it=
=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=C2=B9 If [the compiler, absent a standard change] errored by=
 default,
<br>&gt;&gt; &nbsp;that would make the compiler non-conforming, which for o=
bvious
<br>&gt;&gt; reasons I don't expect the devs to accept. Though I'm not sure=
,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I'm not selling co=
mpilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I'm wrong. (Again, maybe this would be something wher=
e=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div></div></div><div>It's hard to talk about th=
is subject because when you say something it's easy accidentally or intenti=
onally&nbsp;to say more and less than you mean.</div><div>So I'd like to st=
art&nbsp; focus on simple&nbsp;statements&nbsp;to see if we can agree if th=
ey&nbsp;are dubious "as is", then worry separately what fixing it means to =
other statements.</div>


<div>Or how much code it breaks.</div><div>Or how you actually fix it.</div=
><div><br></div><div>Then we can come back and look at it as a whole and na=
rrow it done, give up, or whatever. It makes it simpler to comprehend for p=
eople that aren't language guru's.</div>


<div><br></div><div>So here's some examples:</div><div><br></div><div>#incl=
ude &lt;cstdio&gt; <br>#include &lt;cstddef&gt;<br>using namespace std;<br>=
void fp(char*p) { }<br>void fn( nullptr_t np) { }</div><div>int main()<br>


{<br>&nbsp; char* p =3D nullptr; // I have no desire to break this.</div><d=
iv>&nbsp; fp(nullptr); // No desire to break this<br>&nbsp; fn(nullptr); //=
 I have no desire to break.<br>&nbsp; fn(0); // I'd like to break this. But=
 what else will I break to get this?<br>


</div></div></blockquote><div><br></div><div>A guiding principle we've been=
 using is that std::nullptr_t acts basically like a pointer type (so that, =
for instance, you can use it as a template argument in a template that want=
s something like a pointer type). For that reason, I suspect there will be =
opposition to making this ill-formed.</div>

</div></div></div></blockquote></div></div></div></blockquote><div>[...snip=
....]</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div>
<div><div><span style=3D"color: rgb(34, 34, 34);">What does that mean for t=
his though?:</span><br></div></div></div><div><br></div><div>void f(nullptr=
_t);</div><div>f(0); // I'd like not to allow this, I think.</div>
</div></blockquote><div><br></div><div>See above, before [...snip...]. That=
 code remains valid under the current rules, and there's likely to be oppos=
ition to making nullptr_t and pointer types behave differently here.</div>
</div></div></div></blockquote><div><br></div></div></div><div>Can you give=
 me a 1 or 2 line max example of what kind of&nbsp;code would break other t=
han the above example of preventing 0 converting to nullptr_t implicitly?</=
div>
<div><br></div><div>I'm just trying to understand why someone needs&nbsp;to=
 implicitly convert 0 to nullptr_t and therefore why they'd object to remov=
ing that.</div><div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Maybe once nullptr ga=
ins traction we can consider deprecating the literal zero as a null pointer=
 constant in general, but I wouldn't expect deprecation before C++20, and t=
here will probably be enough people who are over-my-dead-body against that =
we won't ever manage to deprecate or remove it.</div>

<div><br></div><div>The good news is that at least GCC already has a warnin=
g for using the zero literal as a null pointer.</div></div></div></div></bl=
ockquote><div><br></div></div><div>To be clear:</div><div>I understand that=
 this has to work</div>
<div>f( char* );</div><div>f(0);&nbsp;// I get that this wants to be&nbsp;f=
(nullptr) but we can't enforce that yet for compatibility.</div><div>// con=
version tools to the rescue for this.</div><div><br></div><div>But I don't =
understand why:</div>
<div>f(nullptr_t);</div><div>f(0);</div><div>has to work unless it's relate=
d to making&nbsp;the&nbsp;first example&nbsp;work?</div><div><br></div><div=
>I'm sure the answer to this&nbsp;must be&nbsp;obvious&nbsp;to&nbsp;the pot=
ential&nbsp;objectors you&nbsp;mention, but it's&nbsp;unfortunately not cle=
ar to me yet what the objection would be. If anyone objects, I'm keen to he=
ar that to help my understanding of the situation.</div>
</div></blockquote><div><br></div><div>See:</div><div><br></div><div><a onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.ope=
n-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%23654\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNHnR-KXCcnRCaf7yhSJh4ToVVz9LA';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.or=
g%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%23654\46sa\75D\46sntz\0751=
\46usg\75AFQjCNHnR-KXCcnRCaf7yhSJh4ToVVz9LA';return true;" href=3D"http://w=
ww.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2F=
docs%2Fcwg_defects.html%23654&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHnR-K=
XCcnRCaf7yhSJh4ToVVz9LA" target=3D"_blank">http://www.open-std.org/jtc1/<wb=
r>sc22/wg21/docs/cwg_defects.<wbr>html#654</a></div><div>
<br></div><div>The argument that resulted in the current rules is presented=
 there.</div></div></div></div></blockquote><div><br></div><div>Having read=
 the arguments, I didn't find them completely compelling. But may I didn't =
fully understand them or the implications of them.</div><div><br></div><div=
>These two examples, if taken literally:</div><div><pre>    if (nullptr) ; =
     //<span style=3D"font-family: Times; font-style: italic;"> evaluates t=
o </span>false
    if( nullptr =3D=3D 0 ); //<span style=3D"font-family: Times; font-style=
: italic;"> evaluates to </span>true</pre></div><div><br></div><div>Who wou=
ld write such statements as is?</div><div><br></div><div>I don't see it com=
pelling to allow =3D=3D 0 with smart pointers either.</div><div><br></div><=
div>It seems like an attempt to allow the continued dubious practice of usi=
ng 0 with pointers.</div><div>Or&nbsp;enabling new features&nbsp;to be (ab)=
used&nbsp;with old style.</div><div><br></div><div>Something tells me&nbsp;=
I'm missing something obvious here.</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_3033_32620070.1395457920739--

.

--047d7b418c8b0f46f804f538df94
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 21, 2014 at 8:12 PM, <gmisocpp@gmail.com> wrote:

> Hi Richard
>
> On Saturday, March 22, 2014 2:48:32 PM UTC+13, Richard Smith wrote:
>
>> On Fri, Mar 21, 2014 at 5:33 PM, <gmis...@gmail.com> wrote:
>>
>>> Hi Richard
>>>
>>> On Friday, March 21, 2014 12:09:28 PM UTC+13, Richard Smith wrote:
>>>
>>>> On Thu, Mar 20, 2014 at 3:08 PM, <gmis...@gmail.com> wrote:
>>>>
>>>>> Hi Richard
>>>>>
>>>>> On Friday, March 21, 2014 10:29:57 AM UTC+13, Richard Smith wrote:
>>>>>
>>>>>> On Thu, Mar 20, 2014 at 1:27 PM, <gmis...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> On Friday, March 21, 2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:
>>>>>>>
>>>>>>>> On 2014-03-19 21:23, gmis...@gmail.com wrote:
>>>>>>>> > On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke
>>>>>>>> wrote:
>>>>>>>> >> ...but it's "really" warning about comparison with 'nullptr'.
>>>>>>>> I'm
>>>>>>>> >> unconvinced that the implicit conversion of '0' to 'nullptr' ca=
n
>>>>>>>> or
>>>>>>>> >> should be prevented, even in this case. But...
>>>>>>>> >
>>>>>>>> > But I'm not sure implicit conversion of literal 0 to nullptr is
>>>>>>>> good? Why
>>>>>>>> > do you think it's good?
>>>>>>>>
>>>>>>>> Honestly? It would probably make for cleaner code if we could
>>>>>>>> deprecate
>>>>>>>> it. But that's the key word: "if". The amount of code that would
>>>>>>>> break
>>>>>>>> by doing so is appalling, as *all* pre-C++11 code uses '0' to mean
>>>>>>>> 'nullptr'. Thus it is "good" in that it allows pre-C++11 code to b=
e
>>>>>>>> mixed with C++11 code without major (and sometimes
>>>>>>>> near-impossible=B9)
>>>>>>>> porting.
>>>>>>>>
>>>>>>> We don't know how much code we will break until we are sure exactly
>>>>>>> what kind of statements we're considering breaking.
>>>>>>> I'd find it easier if we talk the simplest statements we have
>>>>>>> problems with, agree on that set than find out what else we'd break=
..
>>>>>>> Agree first what we have problems with, separately from too much
>>>>>>> arguing over the implications of changing it.
>>>>>>>
>>>>>>> I'm not sure if everything I want to see is right or possible but I
>>>>>>> feel sure some of it is right and possible and that we can improve =
things
>>>>>>> here, even if a little.
>>>>>>>
>>>>>>> What we need is a clear set of simple statements we all can broadly
>>>>>>> agree are not ideal then see what the impact is of fixing them.
>>>>>>> We need example statements. See below.
>>>>>>>
>>>>>>>
>>>>>>>> Realistically I don't see doing any such thing as being feasible
>>>>>>>> for at
>>>>>>>> least ten years... probably more like fifteen to twenty.
>>>>>>>>
>>>>>>>> (=B9 e.g. use of '0' as 'nullptr' in Qt macros which can't be
>>>>>>>> trivially
>>>>>>>> changed by applications that want to use C++11 but build against a
>>>>>>>> pre-'nullptr'-correct Qt. I'm sure there are other, similar
>>>>>>>> examples;
>>>>>>>> this is one I'm personally familiar with.)
>>>>>>>>
>>>>>>>> >> See previous comments. Right now, "0" here is implicitly
>>>>>>>> converted to
>>>>>>>> >> nullptr. So if we disallow operator< between T* and nullptr_t,
>>>>>>>> we will
>>>>>>>> >> disallow the above. (The only "gotcha" is to make sure that the
>>>>>>>> "0"
>>>>>>>> >> really does convert to "nullptr" and not "(T*)(0)"... and,
>>>>>>>> apparently,
>>>>>>>> >> to resolve that currently there is an overload ambiguity here,
>>>>>>>> although
>>>>>>>> >> given that we want it to be an error, resolving the ambiguity i=
s
>>>>>>>> rather
>>>>>>>> >> superfluous.)
>>>>>>>> >>
>>>>>>>> >> All I'm saying is to not try to interfere with the conversion o=
f
>>>>>>>> "0" to
>>>>>>>> >> nullptr and/or try to prevent the comparison before that
>>>>>>>> conversion
>>>>>>>> >> occurs. (Maybe that was also your intent as well, and I am just
>>>>>>>> confused?)
>>>>>>>> >
>>>>>>>> > These two paragraphs  sounds like the essence of what I'm most
>>>>>>>> interested
>>>>>>>> > in.
>>>>>>>>
>>>>>>>> Right; I think we're on the same page as far as disallowing
>>>>>>>> comparison
>>>>>>>> against an effective literal nullptr, we're just nitpicking whethe=
r
>>>>>>>> it
>>>>>>>> happens before or after implicit conversion of an integer 0 litera=
l
>>>>>>>> to
>>>>>>>> nullptr.
>>>>>>>>
>>>>>>>> >> (=B9 If [the compiler, absent a standard change] errored by
>>>>>>>> default,
>>>>>>>> >>  that would make the compiler non-conforming, which for obvious
>>>>>>>> >> reasons I don't expect the devs to accept. Though I'm not sure,
>>>>>>>> >> e.g. see the stuff that -fpermissive allows; maybe this could b=
e
>>>>>>>> a
>>>>>>>> >> case for that.)
>>>>>>>> >
>>>>>>>> > Really, this would be that bad?
>>>>>>>> > Right is better than conforming to my mind, but I'm not selling
>>>>>>>> compilers.
>>>>>>>>
>>>>>>>> My knee-jerk reaction is that compiler vendors would rather be
>>>>>>>> conforming. Maybe I'm wrong. (Again, maybe this would be something
>>>>>>>> where
>>>>>>>> e.g. gcc would be okay disallowing it without -fpermissive. Though=
,
>>>>>>>> pedantically, the doc says that -fpermissive is for code that is
>>>>>>>> sometimes accepted even though it is non-conforming, whereas this
>>>>>>>> is
>>>>>>>> rather the opposite.)
>>>>>>>>
>>>>>>>> Still... I can only give my own impressions. If you want a
>>>>>>>> worthwhile
>>>>>>>> opinion, take it up with the compiler vendors :-).
>>>>>>>>
>>>>>>>> --
>>>>>>>> Matthew
>>>>>>>>
>>>>>>>>
>>>>>>> It's hard to talk about this subject because when you say something
>>>>>>> it's easy accidentally or intentionally to say more and less than y=
ou mean.
>>>>>>> So I'd like to start  focus on simple statements to see if we can
>>>>>>> agree if they are dubious "as is", then worry separately what fixin=
g it
>>>>>>> means to other statements.
>>>>>>> Or how much code it breaks.
>>>>>>> Or how you actually fix it.
>>>>>>>
>>>>>>> Then we can come back and look at it as a whole and narrow it done,
>>>>>>> give up, or whatever. It makes it simpler to comprehend for people =
that
>>>>>>> aren't language guru's.
>>>>>>>
>>>>>>> So here's some examples:
>>>>>>>
>>>>>>> #include <cstdio>
>>>>>>> #include <cstddef>
>>>>>>> using namespace std;
>>>>>>> void fp(char*p) { }
>>>>>>> void fn( nullptr_t np) { }
>>>>>>> int main()
>>>>>>> {
>>>>>>>   char* p =3D nullptr; // I have no desire to break this.
>>>>>>>   fp(nullptr); // No desire to break this
>>>>>>>   fn(nullptr); // I have no desire to break.
>>>>>>>   fn(0); // I'd like to break this. But what else will I break to
>>>>>>> get this?
>>>>>>>
>>>>>>
>>>>>> A guiding principle we've been using is that std::nullptr_t acts
>>>>>> basically like a pointer type (so that, for instance, you can use it=
 as a
>>>>>> template argument in a template that wants something like a pointer =
type).
>>>>>> For that reason, I suspect there will be opposition to making this
>>>>>> ill-formed.
>>>>>>
>>>>> [...snip...]
>>>>
>>>>  What does that mean for this though?:
>>>>>
>>>>> void f(nullptr_t);
>>>>> f(0); // I'd like not to allow this, I think.
>>>>>
>>>>
>>>> See above, before [...snip...]. That code remains valid under the
>>>> current rules, and there's likely to be opposition to making nullptr_t=
 and
>>>> pointer types behave differently here.
>>>>
>>>
>>> Can you give me a 1 or 2 line max example of what kind of code would
>>> break other than the above example of preventing 0 converting to nullpt=
r_t
>>> implicitly?
>>>
>>> I'm just trying to understand why someone needs to implicitly convert 0
>>> to nullptr_t and therefore why they'd object to removing that.
>>>
>>> Maybe once nullptr gains traction we can consider deprecating the
>>>> literal zero as a null pointer constant in general, but I wouldn't exp=
ect
>>>> deprecation before C++20, and there will probably be enough people who=
 are
>>>> over-my-dead-body against that we won't ever manage to deprecate or re=
move
>>>> it.
>>>>
>>>> The good news is that at least GCC already has a warning for using the
>>>> zero literal as a null pointer.
>>>>
>>>
>>> To be clear:
>>> I understand that this has to work
>>> f( char* );
>>> f(0); // I get that this wants to be f(nullptr) but we can't enforce
>>> that yet for compatibility.
>>> // conversion tools to the rescue for this.
>>>
>>> But I don't understand why:
>>> f(nullptr_t);
>>> f(0);
>>> has to work unless it's related to making the first example work?
>>>
>>> I'm sure the answer to this must be obvious to the potential objectors
>>> you mention, but it's unfortunately not clear to me yet what the object=
ion
>>> would be. If anyone objects, I'm keen to hear that to help my understan=
ding
>>> of the situation.
>>>
>>
>> See:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#654<http://=
www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fcwg_defects.html%23654&sa=3DD&sntz=3D1&usg=3DAFQjCNHnR-KXCcnRCaf7yh=
SJh4ToVVz9LA>
>>
>> The argument that resulted in the current rules is presented there.
>>
>
> Having read the arguments, I didn't find them completely compelling. But
> may I didn't fully understand them or the implications of them.
>
> These two examples, if taken literally:
>
>     if (nullptr) ;      // evaluates to false
>     if( nullptr =3D=3D 0 ); // evaluates to true
>
>
> Who would write such statements as is?
>

I suppose they might arise in a template instantiation, using nullptr_t as
a pointer-like type template argument

I don't see it compelling to allow =3D=3D 0 with smart pointers either.
>
> It seems like an attempt to allow the continued dubious practice of using
> 0 with pointers.
> Or enabling new features to be (ab)used with old style.
>

If using 0 as a null pointer constant were universally regarded as a
dubious practice, I suspect we wouldn't have allowed it for smart pointers
or nullptr_t, but that is not the case. 0 as a null pointer constant is not
even deprecated, and at this point it's mostly a stylistic choice, so it
doesn't seem unreasonable for all of C++'s pointer-like types to support it=
..

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

--047d7b418c8b0f46f804f538df94
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 21, 2014 at 8:12 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmiso=
cpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
<div dir=3D"ltr">Hi Richard<br><br>On Saturday, March 22, 2014 2:48:32 PM U=
TC+13, Richard Smith wrote:<div><div class=3D"h5"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-col=
or:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Mar 21, 2014 at 5:=
33 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">

<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 12:09:28 PM UT=
C+13, Richard Smith wrote:<div><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 3:=
08 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">


<div dir=3D"ltr">Hi Richard<br><br>On Friday, March 21, 2014 10:29:57 AM UT=
C+13, Richard Smith wrote:<div><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">


<div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu, Mar 20, 2014 at 1:=
27 PM,  <span dir=3D"ltr">&lt;<a>gmis...@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">



<div dir=3D"ltr"><div>Hi<br></div><div><br></div><div>On Friday, March 21, =
2014 4:45:24 AM UTC+13, Matthew Woehlke wrote:</div><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">



On 2014-03-19 21:23, <a>gmis...@gmail.com</a> wrote:
<br>&gt; On Thursday, March 20, 2014 10:59:26 AM UTC+13, Matthew Woehlke wr=
ote:
<br>&gt;&gt; ...but it&#39;s &quot;really&quot; warning about comparison wi=
th &#39;nullptr&#39;. I&#39;m
<br>&gt;&gt; unconvinced that the implicit conversion of &#39;0&#39; to &#3=
9;nullptr&#39; can or
<br>&gt;&gt; should be prevented, even in this case. But...
<br>&gt;
<br>&gt; But I&#39;m not sure implicit conversion of literal 0 to nullptr i=
s good? Why
<br>&gt; do you think it&#39;s good?
<br>
<br>Honestly? It would probably make for cleaner code if we could deprecate=
=20
<br>it. But that&#39;s the key word: &quot;if&quot;. The amount of code tha=
t would break=20
<br>by doing so is appalling, as *all* pre-C++11 code uses &#39;0&#39; to m=
ean=20
<br>&#39;nullptr&#39;. Thus it is &quot;good&quot; in that it allows pre-C+=
+11 code to be=20
<br>mixed with C++11 code without major (and sometimes near-impossible=B9)=
=20
<br>porting.
<br></blockquote></div><div>We don&#39;t know how much code we will break u=
ntil we=A0are=A0sure exactly what kind of statements we&#39;re considering =
breaking.</div><div>I&#39;d find it easier if we talk the simplest statemen=
ts we have problems with, agree on that set=A0than find out what else we&#3=
9;d break.</div>



<div>Agree first what we have problems with, separately from too much argui=
ng over the implications of changing it.</div><div><div><br></div></div><di=
v>I&#39;m not sure if everything I want to see is right or possible but I f=
eel sure some of it is right=A0and possible and that we can=A0improve thing=
s here, even if a little.</div>



<div><br></div><div>What we need is a clear set of simple statements we all=
 can broadly agree are not ideal then see what the impact is of fixing them=
..</div><div>We need example statements. See below.</div><div><div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">
<br>Realistically I don&#39;t see doing any such thing as being feasible fo=
r at=20
<br>least ten years... probably more like fifteen to twenty.
<br>
<br>(=B9 e.g. use of &#39;0&#39; as &#39;nullptr&#39; in Qt macros which ca=
n&#39;t be trivially=20
<br>changed by applications that want to use C++11 but build against a=20
<br>pre-&#39;nullptr&#39;-correct Qt. I&#39;m sure there are other, similar=
 examples;=20
<br>this is one I&#39;m personally familiar with.)
<br>
<br>&gt;&gt; See previous comments. Right now, &quot;0&quot; here is implic=
itly converted to
<br>&gt;&gt; nullptr. So if we disallow operator&lt; between T* and nullptr=
_t, we will
<br>&gt;&gt; disallow the above. (The only &quot;gotcha&quot; is to make su=
re that the &quot;0&quot;
<br>&gt;&gt; really does convert to &quot;nullptr&quot; and not &quot;(T*)(=
0)&quot;... and, apparently,
<br>&gt;&gt; to resolve that currently there is an overload ambiguity here,=
 although
<br>&gt;&gt; given that we want it to be an error, resolving the ambiguity =
is rather
<br>&gt;&gt; superfluous.)
<br>&gt;&gt;
<br>&gt;&gt; All I&#39;m saying is to not try to interfere with the convers=
ion of &quot;0&quot; to
<br>&gt;&gt; nullptr and/or try to prevent the comparison before that conve=
rsion
<br>&gt;&gt; occurs. (Maybe that was also your intent as well, and I am jus=
t confused?)
<br>&gt;
<br>&gt; These two paragraphs =A0sounds like the essence of what I&#39;m mo=
st interested
<br>&gt; in.
<br>
<br>Right; I think we&#39;re on the same page as far as disallowing compari=
son=20
<br>against an effective literal nullptr, we&#39;re just nitpicking whether=
 it=20
<br>happens before or after implicit conversion of an integer 0 literal to=
=20
<br>nullptr.
<br>
<br>&gt;&gt; (=B9 If [the compiler, absent a standard change] errored by de=
fault,
<br>&gt;&gt; =A0that would make the compiler non-conforming, which for obvi=
ous
<br>&gt;&gt; reasons I don&#39;t expect the devs to accept. Though I&#39;m =
not sure,
<br>&gt;&gt; e.g. see the stuff that -fpermissive allows; maybe this could =
be a
<br>&gt;&gt; case for that.)
<br>&gt;
<br>&gt; Really, this would be that bad?
<br>&gt; Right is better than conforming to my mind, but I&#39;m not sellin=
g compilers.
<br>
<br>My knee-jerk reaction is that compiler vendors would rather be=20
<br>conforming. Maybe I&#39;m wrong. (Again, maybe this would be something =
where=20
<br>e.g. gcc would be okay disallowing it without -fpermissive. Though,=20
<br>pedantically, the doc says that -fpermissive is for code that is=20
<br>sometimes accepted even though it is non-conforming, whereas this is=20
<br>rather the opposite.)
<br>
<br>Still... I can only give my own impressions. If you want a worthwhile=
=20
<br>opinion, take it up with the compiler vendors :-).
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div></div></div><div>It&#39;s hard to talk abou=
t this subject because when you say something it&#39;s easy accidentally or=
 intentionally=A0to say more and less than you mean.</div><div>So I&#39;d l=
ike to start=A0 focus on simple=A0statements=A0to see if we can agree if th=
ey=A0are dubious &quot;as is&quot;, then worry separately what fixing it me=
ans to other statements.</div>



<div>Or how much code it breaks.</div><div>Or how you actually fix it.</div=
><div><br></div><div>Then we can come back and look at it as a whole and na=
rrow it done, give up, or whatever. It makes it simpler to comprehend for p=
eople that aren&#39;t language guru&#39;s.</div>



<div><br></div><div>So here&#39;s some examples:</div><div><br></div><div>#=
include &lt;cstdio&gt; <br>#include &lt;cstddef&gt;<br>using namespace std;=
<br>void fp(char*p) { }<br>void fn( nullptr_t np) { }</div><div>int main()<=
br>



{<br>=A0 char* p =3D nullptr; // I have no desire to break this.</div><div>=
=A0 fp(nullptr); // No desire to break this<br>=A0 fn(nullptr); // I have n=
o desire to break.<br>=A0 fn(0); // I&#39;d like to break this. But what el=
se will I break to get this?<br>



</div></div></blockquote><div><br></div><div>A guiding principle we&#39;ve =
been using is that std::nullptr_t acts basically like a pointer type (so th=
at, for instance, you can use it as a template argument in a template that =
wants something like a pointer type). For that reason, I suspect there will=
 be opposition to making this ill-formed.</div>


</div></div></div></blockquote></div></div></div></blockquote><div>[...snip=
....]</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);borde=
r-left-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div>
<div><div><span style=3D"color:rgb(34,34,34)">What does that mean for this =
though?:</span><br></div></div></div><div><br></div><div>void f(nullptr_t);=
</div><div>f(0); // I&#39;d like not to allow this, I think.</div>
</div></blockquote><div><br></div><div>See above, before [...snip...]. That=
 code remains valid under the current rules, and there&#39;s likely to be o=
pposition to making nullptr_t and pointer types behave differently here.</d=
iv>

</div></div></div></blockquote><div><br></div></div></div><div>Can you give=
 me a 1 or 2 line max example of what kind of=A0code would break other than=
 the above example of preventing 0 converting to nullptr_t implicitly?</div=
>

<div><br></div><div>I&#39;m just trying to understand why someone needs=A0t=
o implicitly convert 0 to nullptr_t and therefore why they&#39;d object to =
removing that.</div><div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204=
,204,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Maybe once nullptr ga=
ins traction we can consider deprecating the literal zero as a null pointer=
 constant in general, but I wouldn&#39;t expect deprecation before C++20, a=
nd there will probably be enough people who are over-my-dead-body against t=
hat we won&#39;t ever manage to deprecate or remove it.</div>


<div><br></div><div>The good news is that at least GCC already has a warnin=
g for using the zero literal as a null pointer.</div></div></div></div></bl=
ockquote><div><br></div></div><div>To be clear:</div><div>I understand that=
 this has to work</div>

<div>f( char* );</div><div>f(0);=A0// I get that this wants to be=A0f(nullp=
tr) but we can&#39;t enforce that yet for compatibility.</div><div>// conve=
rsion tools to the rescue for this.</div><div><br></div><div>But I don&#39;=
t understand why:</div>

<div>f(nullptr_t);</div><div>f(0);</div><div>has to work unless it&#39;s re=
lated to making=A0the=A0first example=A0work?</div><div><br></div><div>I&#3=
9;m sure the answer to this=A0must be=A0obvious=A0to=A0the potential=A0obje=
ctors you=A0mention, but it&#39;s=A0unfortunately not clear to me yet what =
the objection would be. If anyone objects, I&#39;m keen to hear that to hel=
p my understanding of the situation.</div>

</div></blockquote><div><br></div><div>See:</div><div><br></div><div><a hre=
f=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fs=
c22%2Fwg21%2Fdocs%2Fcwg_defects.html%23654&amp;sa=3DD&amp;sntz=3D1&amp;usg=
=3DAFQjCNHnR-KXCcnRCaf7yhSJh4ToVVz9LA" target=3D"_blank">http://www.open-st=
d.org/jtc1/<u></u>sc22/wg21/docs/cwg_defects.<u></u>html#654</a></div>
<div>
<br></div><div>The argument that resulted in the current rules is presented=
 there.</div></div></div></div></blockquote><div><br></div></div></div><div=
>Having read the arguments, I didn&#39;t find them completely compelling. B=
ut may I didn&#39;t fully understand them or the implications of them.</div=
>
<div><br></div><div>These two examples, if taken literally:</div><div><pre>=
    if (nullptr) ;      //<span style=3D"font-family:Times;font-style:itali=
c"> evaluates to </span>false
    if( nullptr =3D=3D 0 ); //<span style=3D"font-family:Times;font-style:i=
talic"> evaluates to </span>true</pre></div><div><br></div><div>Who would w=
rite such statements as is?</div></div></blockquote><div><br></div><div>I s=
uppose they might arise in a template instantiation, using nullptr_t as a p=
ointer-like type template argument</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>I don&#39;t see it co=
mpelling to allow =3D=3D 0 with smart pointers either.</div>
<div><br></div><div>It seems like an attempt to allow the continued dubious=
 practice of using 0 with pointers.</div><div>Or=A0enabling new features=A0=
to be (ab)used=A0with old style.</div></div></blockquote><div><br></div><di=
v>
If using 0 as a null pointer constant were universally regarded as a dubiou=
s practice, I suspect we wouldn&#39;t have allowed it for smart pointers or=
 nullptr_t, but that is not the case. 0 as a null pointer constant is not e=
ven deprecated, and at this point it&#39;s mostly a stylistic choice, so it=
 doesn&#39;t seem unreasonable for all of C++&#39;s pointer-like types to s=
upport it.</div>
</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 />

--047d7b418c8b0f46f804f538df94--

.

------=_Part_1734_27714150.1395527852324
Content-Type: text/plain; charset=UTF-8

Hi

See:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#654<http://www.google.com/url?q=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.html%23654&sa=D&sntz=1&usg=AFQjCNHnR-KXCcnRCaf7yhSJh4ToVVz9LA>
>>>
>>> The argument that resulted in the current rules is presented there.
>>>
>>
>> Having read the arguments, I didn't find them completely compelling. But
>> may I didn't fully understand them or the implications of them.
>>
>> These two examples, if taken literally:
>>
>>     if (nullptr) ;      // evaluates to false
>>     if( nullptr == 0 ); // evaluates to true
>>
>>
>> Who would write such statements as is?
>>
>
> I suppose they might arise in a template instantiation, using nullptr_t as
> a pointer-like type template argument
>
> I don't see it compelling to allow == 0 with smart pointers either.
>>
>> It seems like an attempt to allow the continued dubious practice of using
>> 0 with pointers.
>> Or enabling new features to be (ab)used with old style.
>>
>
> If using 0 as a null pointer constant were universally regarded as a
> dubious practice, I suspect we wouldn't have allowed it for smart pointers
> or nullptr_t, but that is not the case. 0 as a null pointer constant is not
> even deprecated, and at this point it's mostly a stylistic choice, so it
> doesn't seem unreasonable for all of C++'s pointer-like types to support it.
>

I naively thought the whole reason to introduce nullptr was to (start to)
stop using constant 0 for places where we don't mean an integer (since
that's the first thought when you see a 0) and avoid ambiguous
overloads and now here we are effectively enabling more ways to use 0 where
we don't mean an integer. We're not encouraging people to change style, I
know bjarne himself was a keen proponent of 0, I wonder if he's changed
(Bjarne?). I guess none of this is the biggest of deals but I'm surprised
it's like this.
Time to promote automatic conversion tools then and maybe some new entries
on this on the new C++ FAQ.


--

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

<div dir=3D"ltr">Hi<br><br><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 2=
04); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"=
><div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div>See:</div><div><br></div><div><a onmousedown=3D"this.hre=
f=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fs=
c22%2Fwg21%2Fdocs%2Fcwg_defects.html%23654\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNHnR-KXCcnRCaf7yhSJh4ToVVz9LA';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg2=
1%2Fdocs%2Fcwg_defects.html%23654\46sa\75D\46sntz\0751\46usg\75AFQjCNHnR-KX=
CcnRCaf7yhSJh4ToVVz9LA';return true;" href=3D"http://www.google.com/url?q=
=3Dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_defects.=
html%23654&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHnR-KXCcnRCaf7yhSJh4ToVV=
z9LA" target=3D"_blank">http://www.open-std.org/jtc1/<u></u>s<wbr>c22/wg21/=
docs/cwg_defects.<u></u>html<wbr>#654</a></div>
<div>
<br></div><div>The argument that resulted in the current rules is presented=
 there.</div></div></div></div></blockquote><div><br></div></div></div><div=
>Having read the arguments, I didn't find them completely compelling. But m=
ay I didn't fully understand them or the implications of them.</div>
<div><br></div><div>These two examples, if taken literally:</div><div><pre>=
    if (nullptr) ;      //<span style=3D"font-family: Times; font-style: it=
alic;"> evaluates to </span>false
    if( nullptr =3D=3D 0 ); //<span style=3D"font-family: Times; font-style=
: italic;"> evaluates to </span>true</pre></div><div><br></div><div>Who wou=
ld write such statements as is?</div></div></blockquote><div><br></div><div=
>I suppose they might arise in a template instantiation, using nullptr_t as=
 a pointer-like type template argument</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0=
px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-=
left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>I don't s=
ee it compelling to allow =3D=3D 0 with smart pointers either.</div>
<div><br></div><div>It seems like an attempt to allow the continued dubious=
 practice of using 0 with pointers.</div><div>Or&nbsp;enabling new features=
&nbsp;to be (ab)used&nbsp;with old style.</div></div></blockquote><div><br>=
</div><div>
If using 0 as a null pointer constant were universally regarded as a dubiou=
s practice, I suspect we wouldn't have allowed it for smart pointers or nul=
lptr_t, but that is not the case. 0 as a null pointer constant is not even =
deprecated, and at this point it's mostly a stylistic choice, so it doesn't=
 seem unreasonable for all of C++'s pointer-like types to support it.</div>=
</div></div></div></blockquote><div><br></div><div>I naively thought the wh=
ole reason to introduce nullptr was to (start to) stop using constant 0 for=
 places where we don't mean an integer (since that's the first thought when=
 you see a 0) and avoid ambiguous overloads&nbsp;and now here we are effect=
ively enabling more ways to use 0 where we don't mean an integer. We're not=
 encouraging people to change style, I know bjarne himself was a keen propo=
nent of 0, I wonder if he's changed (Bjarne?). I guess none of this is the =
biggest of deals but I'm surprised it's like this.</div><div>Time to promot=
e automatic conversion tools then and maybe some new entries on this on the=
 new C++ FAQ.</div><div>&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_1734_27714150.1395527852324--

.