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

I've noted in our codebase that we lean heavily on the convenience of
range-based for even when it's not perhaps the best way to express an idea.

//do something to the first item
for (auto& Item : range)
{
    DoSomething(Item);
    break;
}

This pattern leads not only to some clarity problems, but also to
unreachable code warnings (for the loop increment statement) on various
compilers. Range-for is the best way to work with ranges currently but
doesn't very well handle when you only want to operate on the first element
of the range.

Our immediate solutions would be something like
if (range.begin() != range.end())
{
    auto&& Item = *range.begin();
    DoSomething(Item);
}

This is particularly inconvenient compared to range-for and it either means
evaluating begin() twice or declaring an extra variable for begin().

An algorithmic sibling to for_each could be added,
std::for_front( range, DoSomething);

This brings with it some of the inconveniences and optimization issues
experienced of the std algorithm approach.

It seems to me that a range-based if, or some similar control structure,
could help here.
//do something to the first item
if (auto& Item : range)
{
    DoSomething(Item);
}

this would be expanded similar to
{
   auto&& __range = range_expr;
   auto&& __begin = __range.begin();
   if (__begin != __range.end())
   {
     auto& Item = *__begin;
     // your code 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/.

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

<div dir=3D"ltr">I&#39;ve noted in our codebase that we lean heavily on the=
 convenience of range-based for even when it&#39;s not perhaps the best way=
 to express an idea.<div><br></div><div>//do something to the first item</d=
iv><div>for (auto&amp; Item : range)</div><div>{</div><div>=C2=A0 =C2=A0 Do=
Something(Item);</div><div>=C2=A0 =C2=A0 break;</div><div>}</div><div><br><=
/div><div>This pattern leads not only to some clarity problems, but also to=
 unreachable code warnings (for the loop increment statement) on various co=
mpilers. Range-for is the best way to work with ranges currently but doesn&=
#39;t very well handle when you only want to operate on the first element o=
f the range.</div><div><br></div><div>Our immediate solutions would be some=
thing like</div><div>if (range.begin() !=3D range.end())</div><div>{</div><=
div>=C2=A0 =C2=A0 auto&amp;&amp; Item =3D *range.begin();</div><div>=C2=A0 =
=C2=A0 DoSomething(Item);</div><div>}</div><div><br></div><div>This is part=
icularly inconvenient compared to range-for and it either means evaluating =
begin() twice or declaring an extra variable for begin().</div><div><br></d=
iv><div>An algorithmic sibling to for_each could be added,</div><div>std::f=
or_front( range, DoSomething);=C2=A0</div><div><br></div><div>This brings w=
ith it some of the inconveniences and optimization issues experienced of th=
e std algorithm approach.</div><div><br></div><div>It seems to me that a ra=
nge-based if, or some similar control structure, could help here.</div><div=
>//do something to the first item</div><div>if (auto&amp; Item : range)</di=
v><div>{</div><div>=C2=A0 =C2=A0 DoSomething(Item);</div><div>}</div><div><=
br></div><div>this would be expanded similar to</div><div>{</div><div>=C2=
=A0 =C2=A0auto&amp;&amp; __range =3D range_expr;</div><div>=C2=A0 =C2=A0aut=
o&amp;&amp; __begin =3D __range.begin();</div><div>=C2=A0 =C2=A0if (__begin=
 !=3D __range.end())</div><div>=C2=A0 =C2=A0{</div><div>=C2=A0 =C2=A0 =C2=
=A0auto&amp; Item =3D *__begin;</div><div>=C2=A0 =C2=A0 =C2=A0// your code =
here</div><div>=C2=A0 =C2=A0}</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 />

--001a1134f86e890bc205079bbbde--

.

On 2014-11-11 16:12, Brent Friedman wrote:
> I've noted in our codebase that we lean heavily on the convenience of
> range-based for even when it's not perhaps the best way to express an idea.
>
> //do something to the first item
> for (auto& Item : range)
> {
>     DoSomething(Item);
>     break;
> }

    auto first_or_null(auto range) -> decltype(&range.begin())
    {
        auto begin = range.begin();
        auto end = range.end();
        return (begin == end ? nullptr : &(*begin));
    }

    if (auto item = first_or_null(range))

Basically you want that, right? :-)

I'm not sure if that actually works, and it requires an additional
dereference when you go to use 'item', but OTOH it wouldn't require a
language change...

That said, how often can you not write:

    if (!range.empty())
        DoSomething(*range.begin());

....?

--
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_1183_390031277.1415744765776
Content-Type: text/plain; charset=UTF-8

Or use the new free function size, count or whatever it is eventually
called, or maybe there is an empty() too in the works:

if (!std::empty(range))
    DoSomething(*begin(range));



Den tisdagen den 11:e november 2014 kl. 22:34:39 UTC+1 skrev Matthew
Woehlke:
>
> On 2014-11-11 16:12, Brent Friedman wrote:
> > I've noted in our codebase that we lean heavily on the convenience of
> > range-based for even when it's not perhaps the best way to express an
> idea.
> >
> > //do something to the first item
> > for (auto& Item : range)
> > {
> >     DoSomething(Item);
> >     break;
> > }
>
>     auto first_or_null(auto range) -> decltype(&range.begin())
>     {
>         auto begin = range.begin();
>         auto end = range.end();
>         return (begin == end ? nullptr : &(*begin));
>     }
>
>     if (auto item = first_or_null(range))
>
> Basically you want that, right? :-)
>
> I'm not sure if that actually works, and it requires an additional
> dereference when you go to use 'item', but OTOH it wouldn't require a
> language change...
>
> That said, how often can you not write:
>
>     if (!range.empty())
>         DoSomething(*range.begin());
>
> ...?
>
> --
> 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_1183_390031277.1415744765776
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Or use the new free function size, count or whatever it is=
 eventually called, or maybe there is an empty() too in the works:<div><br>=
</div><div>if (!std::empty(range))</div><div>&nbsp; &nbsp; DoSomething(*beg=
in(range));</div><div><br></div><div><br><br>Den tisdagen den 11:e november=
 2014 kl. 22:34:39 UTC+1 skrev Matthew Woehlke:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">On 2014-11-11 16:12, Brent Friedman wrote:
<br>&gt; I've noted in our codebase that we lean heavily on the convenience=
 of
<br>&gt; range-based for even when it's not perhaps the best way to express=
 an idea.
<br>&gt;=20
<br>&gt; //do something to the first item
<br>&gt; for (auto&amp; Item : range)
<br>&gt; {
<br>&gt; &nbsp; &nbsp; DoSomething(Item);
<br>&gt; &nbsp; &nbsp; break;
<br>&gt; }
<br>
<br>&nbsp; &nbsp; auto first_or_null(auto range) -&gt; decltype(&amp;range.=
begin())
<br>&nbsp; &nbsp; {
<br>&nbsp; &nbsp; &nbsp; &nbsp; auto begin =3D range.begin();
<br>&nbsp; &nbsp; &nbsp; &nbsp; auto end =3D range.end();
<br>&nbsp; &nbsp; &nbsp; &nbsp; return (begin =3D=3D end ? nullptr : &amp;(=
*begin));
<br>&nbsp; &nbsp; }
<br>
<br>&nbsp; &nbsp; if (auto item =3D first_or_null(range))
<br>
<br>Basically you want that, right? :-)
<br>
<br>I'm not sure if that actually works, and it requires an additional
<br>dereference when you go to use 'item', but OTOH it wouldn't require a
<br>language change...
<br>
<br>That said, how often can you not write:
<br>
<br>&nbsp; &nbsp; if (!range.empty())
<br>&nbsp; &nbsp; &nbsp; &nbsp; DoSomething(*range.begin());
<br>
<br>...?
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></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_1183_390031277.1415744765776--

.

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

> auto first_or_null(auto range) -> decltype(&range.begin())

This assumes pointers, which while addressing some use cases it isn't
sufficient for the general case.

>    if (!range.empty())
>        DoSomething(*range.begin());

This is more or less what we're doing currently. If you need to do more
than one something, then it becomes

if (!range.empty())
{
    auto&& front = *range.begin();
    DoSomething( front );
    //etc
}

'range' may of course be an rvalue, perhaps the result of a function call.
We do this a lot. Currently, we'll have to create a variable to store
'range'. So introducing an additional scope would be wise to contain
'range'.

{
  auto& range = GetTheRange();
  if (!range.empty())
  {
      auto& front = *range.begin();
      DoSomething( front );
      //etc
  }
}

In the face of this worst-case alternative, I think it's only reasonable
that someone would prefer the range-for-with-a-break.

Anecdotally, in our codebase of a million or so LOC, this pattern of using
a looping structure to get the first element in a range constituted about
70% of our unreachable code instances.


On Tue, Nov 11, 2014 at 3:34 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-11-11 16:12, Brent Friedman wrote:
> > I've noted in our codebase that we lean heavily on the convenience of
> > range-based for even when it's not perhaps the best way to express an
> idea.
> >
> > //do something to the first item
> > for (auto& Item : range)
> > {
> >     DoSomething(Item);
> >     break;
> > }
>
>     auto first_or_null(auto range) -> decltype(&range.begin())
>     {
>         auto begin = range.begin();
>         auto end = range.end();
>         return (begin == end ? nullptr : &(*begin));
>     }
>
>     if (auto item = first_or_null(range))
>
> Basically you want that, right? :-)
>
> I'm not sure if that actually works, and it requires an additional
> dereference when you go to use 'item', but OTOH it wouldn't require a
> language change...
>
> That said, how often can you not write:
>
>     if (!range.empty())
>         DoSomething(*range.begin());
>
> ...?
>
> --
> 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/.
>

--

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

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

<div dir=3D"ltr">&gt;<span style=3D"font-family:arial,sans-serif;font-size:=
13px">=C2=A0auto first_or_null(auto range) -&gt; decltype(&amp;range.begin(=
))</span><div><br></div><div>This assumes pointers, which while addressing =
some use cases it isn&#39;t sufficient for the general case.</div><div><br>=
</div><div>&gt;<span style=3D"font-family:arial,sans-serif;font-size:13px">=
=C2=A0 =C2=A0 if (!range.empty())</span></div><span style=3D"font-family:ar=
ial,sans-serif;font-size:13px">&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0DoSomething(=
*range.begin());</span><div><br></div><div>This is more or less what we&#39=
;re doing currently. If you need to do more than one something, then it bec=
omes</div><div><br></div><div>if (!range.empty())</div><div>{</div><div>=C2=
=A0 =C2=A0 auto&amp;&amp; front =3D *range.begin();</div><div>=C2=A0 =C2=A0=
 DoSomething( front );</div><div>=C2=A0 =C2=A0 //etc</div><div>}</div><div>=
<br></div><div>&#39;range&#39; may of course be an rvalue, perhaps the resu=
lt of a function call. We do this a lot. Currently, we&#39;ll have to creat=
e a variable to store &#39;range&#39;. So introducing an additional scope w=
ould be wise to contain &#39;range&#39;.</div><div><br></div><div>{</div><d=
iv>=C2=A0 auto&amp; range =3D GetTheRange();</div><div>=C2=A0 if (!range.em=
pty())</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 auto&amp; front =
=3D *range.begin();</div><div>=C2=A0 =C2=A0 =C2=A0 DoSomething( front );</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 //etc</div><div>=C2=A0 }</div><div>}</div><div=
><br></div><div>In the face of this worst-case alternative, I think it&#39;=
s only reasonable that someone would prefer the range-for-with-a-break.</di=
v><div><br></div><div>Anecdotally, in our codebase of a million or so LOC, =
this pattern of using a looping structure to get the first element in a ran=
ge constituted about 70% of our unreachable code instances.</div><div>=C2=
=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 Tue, Nov 11, 2014 at 3:34 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@user=
s.sourceforge.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
span class=3D"">On 2014-11-11 16:12, Brent Friedman wrote:<br>
&gt; I&#39;ve noted in our codebase that we lean heavily on the convenience=
 of<br>
&gt; range-based for even when it&#39;s not perhaps the best way to express=
 an idea.<br>
&gt;<br>
&gt; //do something to the first item<br>
&gt; for (auto&amp; Item : range)<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0 =C2=A0DoSomething(Item);<br>
&gt;=C2=A0 =C2=A0 =C2=A0break;<br>
&gt; }<br>
<br>
</span>=C2=A0 =C2=A0 auto first_or_null(auto range) -&gt; decltype(&amp;ran=
ge.begin())<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto begin =3D range.begin();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto end =3D range.end();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return (begin =3D=3D end ? nullptr : &amp;(*beg=
in));<br>
=C2=A0 =C2=A0 }<br>
<br>
=C2=A0 =C2=A0 if (auto item =3D first_or_null(range))<br>
<br>
Basically you want that, right? :-)<br>
<br>
I&#39;m not sure if that actually works, and it requires an additional<br>
dereference when you go to use &#39;item&#39;, but OTOH it wouldn&#39;t req=
uire a<br>
language change...<br>
<br>
That said, how often can you not write:<br>
<br>
=C2=A0 =C2=A0 if (!range.empty())<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DoSomething(*range.begin());<br>
<br>
....?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
<br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

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

--001a1130c512468fb00507a04e91--

.

On Tuesday 11 November 2014 20:39:32 Brent Friedman wrote:
> Anecdotally, in our codebase of a million or so LOC, this pattern of using
> a looping structure to get the first element in a range constituted about
> 70% of our unreachable code instances.

I must be missing something: what wasn't reachable?

All three non-comment lines in your example would be executed for a non-empty
range:

for (auto& Item : range)
{
    DoSomething(Item);
    break;
}

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

--

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

.

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

> I must be missing something: what wasn't reachable?

When you break on the first iteration, the code that advances the iterator
can never be executed. We see this both for 'normal' for loops and for
range-for loops.

It might be easy to say that this is something that vendors should fix, but
I think that the warning is good and valuable as it is. By turning on this
warning we've found a few places where the premature loop exit was actually
unintentional. This is why I think a different control structure might be a
better solution. It can make intent clearer to man and machine.

On Tue, Nov 11, 2014 at 10:13 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Tuesday 11 November 2014 20:39:32 Brent Friedman wrote:
> > Anecdotally, in our codebase of a million or so LOC, this pattern of
> using
> > a looping structure to get the first element in a range constituted about
> > 70% of our unreachable code instances.
>
> I must be missing something: what wasn't reachable?
>
> All three non-comment lines in your example would be executed for a
> non-empty
> range:
>
> for (auto& Item : range)
> {
>     DoSomething(Item);
>     break;
> }
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:arial,sans-serif;font=
-size:13px">I must be missing something: what wasn&#39;t reachable?</span><=
div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span>=
</div><div><font face=3D"arial, sans-serif">When you break on the first ite=
ration, the code that advances the iterator can never be executed. We see t=
his both for &#39;normal&#39; for loops and for range-for loops.</font></di=
v><div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D=
"arial, sans-serif">It might be easy to say that this is something that ven=
dors should fix, but I think that the warning is good and valuable as it is=
.. By turning on this warning we&#39;ve found a few places where the prematu=
re loop exit was actually unintentional. This is why I think a different co=
ntrol structure might be a better solution. It can make intent clearer to m=
an and machine.</font></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, Nov 11, 2014 at 10:13 PM, Thiago Macieira <span di=
r=3D"ltr">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thia=
go@macieira.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><sp=
an class=3D"">On Tuesday 11 November 2014 20:39:32 Brent Friedman wrote:<br=
>
&gt; Anecdotally, in our codebase of a million or so LOC, this pattern of u=
sing<br>
&gt; a looping structure to get the first element in a range constituted ab=
out<br>
&gt; 70% of our unreachable code instances.<br>
<br>
</span>I must be missing something: what wasn&#39;t reachable?<br>
<br>
All three non-comment lines in your example would be executed for a non-emp=
ty<br>
range:<br>
<span class=3D"im HOEnZb"><br>
for (auto&amp; Item : range)<br>
{<br>
=C2=A0 =C2=A0 DoSomething(Item);<br>
=C2=A0 =C2=A0 break;<br>
}<br>
<br>
</span><span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</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 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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a113d235c78d2a60507a3d057--

.

------=_Part_898_1511322349.1415820809109
Content-Type: text/plain; charset=UTF-8

On Wednesday, November 12, 2014 3:39:34 AM UTC+1, Brent Friedman wrote:
>
> > auto first_or_null(auto range) -> decltype(&range.begin())
>
> This assumes pointers, which while addressing some use cases it isn't
> sufficient for the general case.
>
> >    if (!range.empty())
> >        DoSomething(*range.begin());
>
> This is more or less what we're doing currently. If you need to do more
> than one something, then it becomes
>
> if (!range.empty())
> {
>     auto&& front = *range.begin();
>     DoSomething( front );
>     //etc
> }
>
> 'range' may of course be an rvalue, perhaps the result of a function call.
> We do this a lot. Currently, we'll have to create a variable to store
> 'range'. So introducing an additional scope would be wise to contain
> 'range'.
>
> {
>   auto& range = GetTheRange();
>   if (!range.empty())
>   {
>       auto& front = *range.begin();
>       DoSomething( front );
>       //etc
>   }
> }
>
>
IMO it'd be nice if this was possible:
if (auto& range = GetTheRange())

--

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

<div dir=3D"ltr">On Wednesday, November 12, 2014 3:39:34 AM UTC+1, Brent Fr=
iedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
&gt;<span style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp;auto =
first_or_null(auto range) -&gt; decltype(&amp;range.begin())</span><div><br=
></div><div>This assumes pointers, which while addressing some use cases it=
 isn't sufficient for the general case.</div><div><br></div><div>&gt;<span =
style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp; &nbsp; if (!ra=
nge.empty())</span></div><span style=3D"font-family:arial,sans-serif;font-s=
ize:13px">&gt; &nbsp; &nbsp; &nbsp; &nbsp;DoSomething(*range.begin());</spa=
n><div><br></div><div>This is more or less what we're doing currently. If y=
ou need to do more than one something, then it becomes</div><div><br></div>=
<div>if (!range.empty())</div><div>{</div><div>&nbsp; &nbsp; auto&amp;&amp;=
 front =3D *range.begin();</div><div>&nbsp; &nbsp; DoSomething( front );</d=
iv><div>&nbsp; &nbsp; //etc</div><div>}</div><div><br></div><div>'range' ma=
y of course be an rvalue, perhaps the result of a function call. We do this=
 a lot. Currently, we'll have to create a variable to store 'range'. So int=
roducing an additional scope would be wise to contain 'range'.</div><div><b=
r></div><div>{</div><div>&nbsp; auto&amp; range =3D GetTheRange();</div><di=
v>&nbsp; if (!range.empty())</div><div>&nbsp; {</div><div>&nbsp; &nbsp; &nb=
sp; auto&amp; front =3D *range.begin();</div><div>&nbsp; &nbsp; &nbsp; DoSo=
mething( front );</div><div>&nbsp; &nbsp; &nbsp; //etc</div><div>&nbsp; }</=
div><div>}</div><div><br></div></div></blockquote><div><br></div><div>IMO i=
t'd be nice if this was possible:</div><div>if (auto&amp; range =3D GetTheR=
ange())<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
">
</blockquote></div>

<p></p>

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

------=_Part_898_1511322349.1415820809109--

.

On Wednesday 12 November 2014 00:50:42 Brent Friedman wrote:
> > I must be missing something: what wasn't reachable?
>
> When you break on the first iteration, the code that advances the iterator
> can never be executed. We see this both for 'normal' for loops and for
> range-for loops.

So what? All the lines got executed. The fact that some assembly instructions
did not get executed is not important. You should also report a missed
optimisation opportunity bug report to your compiler, as it should be able to
realise that the code will never loop and forego emitting the code that does
the looping.

> It might be easy to say that this is something that vendors should fix, but
> I think that the warning is good and valuable as it is. By turning on this
> warning we've found a few places where the premature loop exit was actually
> unintentional. This is why I think a different control structure might be a
> better solution. It can make intent clearer to man and machine.

I agree I would have written the code differently, but I don't think
overloading the if command for this purpose is the right thing to do. I'd
reserve if (x : y) for some other, future purpose.

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

--

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

.

On Wednesday 12 November 2014 11:33:29 Olaf van der Spek wrote:
> IMO it'd be nice if this was possible:
> if (auto& range = GetTheRange())

All you need is that range's type provide a conversion to bool that indicates
whether it's empty or not.

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

--

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

.

------=_Part_976_775498106.1415843033974
Content-Type: text/plain; charset=UTF-8



On Tuesday, November 11, 2014 8:39:34 PM UTC-6, Brent Friedman wrote:
>
> > auto first_or_null(auto range) -> decltype(&range.begin())
>
> This assumes pointers, which while addressing some use cases it isn't
> sufficient for the general case.
>
>
What case does it not handle? And what exactly do you mean by "This assumes
pointers"? It doesn't assume that the iterators are pointers, if that's
what you mean.

--

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

<div dir=3D"ltr"><br><br>On Tuesday, November 11, 2014 8:39:34 PM UTC-6, Br=
ent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">&gt;<span style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp=
;auto first_or_null(auto range) -&gt; decltype(&amp;range.begin())</span><d=
iv><br></div><div>This assumes pointers, which while addressing some use ca=
ses it isn't sufficient for the general case.</div><div><br></div></div></b=
lockquote><div><br>What case does it not handle? And what exactly do you me=
an by "This assumes pointers"? It doesn't assume that the iterators are poi=
nters, if that's what you mean. <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_976_775498106.1415843033974--

.

--Apple-Mail=_59DB2EBF-179C-4FEF-BF84-6733EF7CD3D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9313, at 9:43 AM, Benjamin Lindley <benjameslindle=
y@gmail.com> wrote:

>=20
>=20
> On Tuesday, November 11, 2014 8:39:34 PM UTC-6, Brent Friedman wrote:
> > auto first_or_null(auto range) -> decltype(&range.begin())
>=20
> This assumes pointers, which while addressing some use cases it isn't suf=
ficient for the general case.
>=20
>=20
> What case does it not handle? And what exactly do you mean by "This assum=
es pointers"? It doesn't assume that the iterators are pointers, if that's =
what you mean.=20

It doesn=E2=80=99t cover smart pointers.

There was a formal proposal for range-if syntax, named =E2=80=9CChecked-der=
eference conditions=E2=80=9D (http://open-std.org/jtc1/sc22/wg21/docs/paper=
s/2014/n4127.html), which seems to be more evolved than what=E2=80=99s prop=
osed in this thread. I recall that I was swayed in its favor at the meeting=
, but others weren=E2=80=99t.

--=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=_59DB2EBF-179C-4FEF-BF84-6733EF7CD3D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<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=
=E2=80=9311=E2=80=9313, at 9:43 AM, Benjamin Lindley &lt;<a href=3D"mailto:=
benjameslindley@gmail.com">benjameslindley@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D=
"ltr"><br><br>On Tuesday, November 11, 2014 8:39:34 PM UTC-6, Brent Friedma=
n wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">&gt;<=
span style=3D"font-family:arial,sans-serif;font-size:13px">&nbsp;auto first=
_or_null(auto range) -&gt; decltype(&amp;range.begin())</span><div><br></di=
v><div>This assumes pointers, which while addressing some use cases it isn'=
t sufficient for the general case.</div><div><br></div></div></blockquote><=
div><br>What case does it not handle? And what exactly do you mean by "This=
 assumes pointers"? It doesn't assume that the iterators are pointers, if t=
hat's what you mean. <br></div></div></blockquote><div><br></div><div>It do=
esn=E2=80=99t cover smart pointers.</div><div><br></div><div>There was a fo=
rmal proposal for range-if syntax, named =E2=80=9CChecked-dereference condi=
tions=E2=80=9D (<a href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2=
014/n4127.html">http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4127.h=
tml</a>), which seems to be more evolved than what=E2=80=99s proposed in th=
is thread. I recall that I was swayed in its favor at the meeting, but othe=
rs weren=E2=80=99t.</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=_59DB2EBF-179C-4FEF-BF84-6733EF7CD3D0--

.

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

> It doesn't assume that the iterators are pointers, if that's what you
mean.
It assumes that it is possible to convert from nullptr_t to
decltype(&range.begin()).
It also assumes that this value constructed from nullptr necessarily
represents an invalid value (converts to false) for that iterator type.

On Wed, Nov 12, 2014 at 7:43 PM, Benjamin Lindley <benjameslindley@gmail.com
> wrote:

>
>
> On Tuesday, November 11, 2014 8:39:34 PM UTC-6, Brent Friedman wrote:
>>
>> > auto first_or_null(auto range) -> decltype(&range.begin())
>>
>> This assumes pointers, which while addressing some use cases it isn't
>> sufficient for the general case.
>>
>>
> What case does it not handle? And what exactly do you mean by "This
> assumes pointers"? It doesn't assume that the iterators are pointers, if
> that's what you mean.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:arial,sans-serif;font=
-size:13px">It doesn&#39;t assume that the iterators are pointers, if that&=
#39;s what you mean.</span><div><span style=3D"font-family:arial,sans-serif=
;font-size:13px">It assumes that it is possible to convert from nullptr_t t=
o=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">d=
ecltype(&amp;range.begin()). It also assumes that this value constructed fr=
om nullptr necessarily represents an invalid value (converts to false) for =
that iterator type.</span></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Wed, Nov 12, 2014 at 7:43 PM, Benjamin Lindley <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:benjameslindley@gmail.com" target=3D"_b=
lank">benjameslindley@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Tuesday, Novembe=
r 11, 2014 8:39:34 PM UTC-6, Brent Friedman wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">&gt;<span style=3D"font-family:arial,sans-s=
erif;font-size:13px">=C2=A0auto first_or_null(auto range) -&gt; decltype(&a=
mp;range.begin())</span><div><br></div><div>This assumes pointers, which wh=
ile addressing some use cases it isn&#39;t sufficient for the general case.=
</div><div><br></div></div></blockquote></span><div><br>What case does it n=
ot handle? And what exactly do you mean by &quot;This assumes pointers&quot=
;? It doesn&#39;t assume that the iterators are pointers, if that&#39;s wha=
t you mean. <br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

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

<p></p>

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

--001a11352dfcaa83040507b44ffd--

.

------=_Part_820_556048964.1415846855659
Content-Type: text/plain; charset=UTF-8



On Wednesday, November 12, 2014 8:31:37 PM UTC-6, Brent Friedman wrote:
>
> > It doesn't assume that the iterators are pointers, if that's what you
> mean.
> It assumes that it is possible to convert from nullptr_t to decltype(&range.begin()).
> It also assumes that this value constructed from nullptr necessarily
> represents an invalid value (converts to false) for that iterator type.
>
>
Well, I'm pretty sure that Matthew wrote that in a hurry, and it should
really be decltype(std::addressof(*std::begin(range)). The idea is, it is a
pointer (how can it not be?). In which case, it can of course convert from
nullptr_t.

--

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

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

<div dir=3D"ltr"><br><br>On Wednesday, November 12, 2014 8:31:37 PM UTC-6, =
Brent Friedman wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">&gt;&nbsp;<span style=3D"font-family:arial,sans-serif;font-size:13=
px">It doesn't assume that the iterators are pointers, if that's what you m=
ean.</span><div><span style=3D"font-family:arial,sans-serif;font-size:13px"=
>It assumes that it is possible to convert from nullptr_t to&nbsp;</span><s=
pan style=3D"font-family:arial,sans-serif;font-size:13px">decltype(&amp;ran=
ge.begin()). It also assumes that this value constructed from nullptr neces=
sarily represents an invalid value (converts to false) for that iterator ty=
pe.</span></div></div><div><br></div></blockquote><div><br>Well, I'm pretty=
 sure that Matthew wrote that in a hurry, and it should really be decltype(=
std::addressof(*std::begin(range)). The idea is, it is a pointer (how can i=
t not be?). In which case, it can of course convert from nullptr_t.<br></di=
v></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_820_556048964.1415846855659--

.

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

> The idea is, it is a pointer (how can it not be?).

It absolutely doesn't have to be a pointer. We use range adaptors in our
code for filtering, mapping, dynamic_casting, and the like. These iterators
are not pointers, and cannot be constructed from nullptr_t. We also have
counting iterators that store and increment a number, so there's not even a
notion of some underlying memory location at all.

A function like first_or_null which returns an optional<T&> could probably
work alright for our purposes with only a bit of extra syntax over this
range-if idea.

On Wed, Nov 12, 2014 at 8:47 PM, Benjamin Lindley <benjameslindley@gmail.com
> wrote:

>
>
> On Wednesday, November 12, 2014 8:31:37 PM UTC-6, Brent Friedman wrote:
>>
>> > It doesn't assume that the iterators are pointers, if that's what you
>> mean.
>> It assumes that it is possible to convert from nullptr_t to decltype(&range.begin()).
>> It also assumes that this value constructed from nullptr necessarily
>> represents an invalid value (converts to false) for that iterator type.
>>
>>
> Well, I'm pretty sure that Matthew wrote that in a hurry, and it should
> really be decltype(std::addressof(*std::begin(range)). The idea is, it is a
> pointer (how can it not be?). In which case, it can of course convert from
> nullptr_t.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:arial,sans-serif;font=
-size:13px">The idea is, it is a pointer (how can it not be?).=C2=A0</span>=
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><font face=3D"arial, sans-serif">It absolutely doesn&#39;t have=
 to be a pointer. We use range adaptors in our code for filtering, mapping,=
 dynamic_casting, and the like. These iterators are not pointers, and canno=
t be constructed from nullptr_t. We also have counting iterators that store=
 and increment a number, so there&#39;s not even a notion of some underlyin=
g memory location at all.</font></div><div><font face=3D"arial, sans-serif"=
><br></font></div><div><font face=3D"arial, sans-serif">A function like fir=
st_or_null which returns an optional&lt;T&amp;&gt; could probably work alri=
ght for our purposes with only a bit of extra syntax over this range-if ide=
a.=C2=A0</font></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Wed, Nov 12, 2014 at 8:47 PM, Benjamin Lindley <span dir=3D"lt=
r">&lt;<a href=3D"mailto:benjameslindley@gmail.com" target=3D"_blank">benja=
meslindley@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><span class=3D""><br><br>On Wednesday, November 12, 2014=
 8:31:37 PM UTC-6, Brent Friedman wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-family:arial,sans-serif=
;font-size:13px">It doesn&#39;t assume that the iterators are pointers, if =
that&#39;s what you mean.</span><div><span style=3D"font-family:arial,sans-=
serif;font-size:13px">It assumes that it is possible to convert from nullpt=
r_t to=C2=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13=
px">decltype(&amp;range.begin()). It also assumes that this value construct=
ed from nullptr necessarily represents an invalid value (converts to false)=
 for that iterator type.</span></div></div><div><br></div></blockquote></sp=
an><div><br>Well, I&#39;m pretty sure that Matthew wrote that in a hurry, a=
nd it should really be decltype(std::addressof(*std::begin(range)). The ide=
a is, it is a pointer (how can it not be?). In which case, it can of course=
 convert from nullptr_t.<br></div></div><div class=3D"HOEnZb"><div class=3D=
"h5">

<p></p>

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

<p></p>

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

--001a1137d89e04f47e0507b4998a--

.

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



On Wednesday, November 12, 2014 8:31:35 PM UTC-6, David Krauss wrote:
>
>
> On 2014=E2=80=9311=E2=80=9313, at 9:43 AM, Benjamin Lindley <benjame...@g=
mail.com=20
> <javascript:>> wrote:
>
>
>
> On Tuesday, November 11, 2014 8:39:34 PM UTC-6, Brent Friedman wrote:
>>
>> > auto first_or_null(auto range) -> decltype(&range.begin())
>>
>> This assumes pointers, which while addressing some use cases it isn't=20
>> sufficient for the general case.
>>
>>
> What case does it not handle? And what exactly do you mean by "This=20
> assumes pointers"? It doesn't assume that the iterators are pointers, if=
=20
> that's what you mean.=20
>
>
> It doesn=E2=80=99t cover smart pointers.
>

Smart pointers aren't ranges that have a first element, so I'm not sure why=
=20
you would expect them to be covered by this. The proposal you refer to=20
solves a completely different problem, afaict.

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

<div dir=3D"ltr"><br><br>On Wednesday, November 12, 2014 8:31:35 PM UTC-6, =
David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=9311=E2=80=9313, at 9=
:43 AM, Benjamin Lindley &lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"gckUZmEC924J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">benjame..=
..@gmail.com</a>&gt; wrote:</div><br><blockquote type=3D"cite"><div dir=3D"l=
tr"><br><br>On Tuesday, November 11, 2014 8:39:34 PM UTC-6, Brent Friedman =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">&gt;<span st=
yle=3D"font-family:arial,sans-serif;font-size:13px">&nbsp;auto first_or_nul=
l(auto range) -&gt; decltype(&amp;range.begin())</span><div><br></div><div>=
This assumes pointers, which while addressing some use cases it isn't suffi=
cient for the general case.</div><div><br></div></div></blockquote><div><br=
>What case does it not handle? And what exactly do you mean by "This assume=
s pointers"? It doesn't assume that the iterators are pointers, if that's w=
hat you mean. <br></div></div></blockquote><div><br></div><div>It doesn=E2=
=80=99t cover smart pointers.</div></div></div></blockquote><div><br>Smart =
pointers aren't ranges that have a first element, so I'm not sure why you w=
ould expect them to be covered by this. The proposal you refer to solves a =
completely different problem, afaict.<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_930_1062945902.1415847204756--

.

On 2014-11-12 21:31, Brent Friedman wrote:
>> It doesn't assume that the iterators are pointers, if that's what you
>> mean.
>
> It assumes that it is possible to convert from nullptr_t to
> decltype(&range.begin()).

Oops, yes, there is a '*' missing: 'decltype(&*range.begin())' (or
std::addressof as Benjamin suggested). This should be obvious
considering the RHS of the 'return'.

I am confused; I am not returning the iterator. I am returning the
address of the iterator's value. While I would believe that might not be
possible in all cases, I don't see how it relates to the cases you are
concerned about. (Also, my C++11-fu is not that strong; there may be a
way to return the iterator value as a form of reference that would
bypass these issues also.)

On 2014-11-12 21:52, Brent Friedman wrote:
> A function like first_or_null which returns an optional<T&> could probably
> work alright for our purposes with only a bit of extra syntax over this
> range-if idea.

Brent, that's basically *what I wrote*, except using T* rather than
optional<T&>. Certainly it's the same general idea.

> It also assumes that this value constructed from nullptr necessarily
> represents an invalid value (converts to false) for that iterator type.

Huh? The check is on begin == end. No other assumptions are made about
the behavior of begin except that operator==(end) will return true if
the range is not valid. Since AFAIUI this is how range-based for also
works, if this assumption is being violated I'd think you'd have other
problems...

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

.

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

I believe I was misinterpreting your intent. I had interpreted &begin() as
a *begin() typo, not a &*begin() typo. If the intent is to return
pointer-to-dereferenced-value, then that creates a separate issue. If
*begin() returns say int (rather than int&) then that would return
pointer-to-temporary-on-the-stack.

>Brent, that's basically *what I wrote*, except using T* rather than optional<T&>.
Certainly it's the same general idea.
I agree.

On Thu, Nov 13, 2014 at 10:23 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-11-12 21:31, Brent Friedman wrote:
> >> It doesn't assume that the iterators are pointers, if that's what you
> >> mean.
> >
> > It assumes that it is possible to convert from nullptr_t to
> > decltype(&range.begin()).
>
> Oops, yes, there is a '*' missing: 'decltype(&*range.begin())' (or
> std::addressof as Benjamin suggested). This should be obvious
> considering the RHS of the 'return'.
>
> I am confused; I am not returning the iterator. I am returning the
> address of the iterator's value. While I would believe that might not be
> possible in all cases, I don't see how it relates to the cases you are
> concerned about. (Also, my C++11-fu is not that strong; there may be a
> way to return the iterator value as a form of reference that would
> bypass these issues also.)
>
> On 2014-11-12 21:52, Brent Friedman wrote:
> > A function like first_or_null which returns an optional<T&> could
> probably
> > work alright for our purposes with only a bit of extra syntax over this
> > range-if idea.
>
> Brent, that's basically *what I wrote*, except using T* rather than
> optional<T&>. Certainly it's the same general idea.
>
> > It also assumes that this value constructed from nullptr necessarily
> > represents an invalid value (converts to false) for that iterator type.
>
> Huh? The check is on begin == end. No other assumptions are made about
> the behavior of begin except that operator==(end) will return true if
> the range is not valid. Since AFAIUI this is how range-based for also
> works, if this assumption is being violated I'd think you'd have other
> problems...
>
> --
> 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/.
>

--

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

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

<div dir=3D"ltr">I believe I was misinterpreting your intent. I had interpr=
eted &amp;begin() as a *begin() typo, not a &amp;*begin() typo. If the inte=
nt is to return pointer-to-dereferenced-value, then that creates a separate=
 issue. If *begin() returns say int (rather than int&amp;) then that would =
return pointer-to-temporary-on-the-stack.=C2=A0<div><br></div><div>&gt;<spa=
n style=3D"font-family:arial,sans-serif;font-size:13px">Brent, that&#39;s b=
asically *what I wrote*, except using T* rather than=C2=A0</span><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px">optional&lt;T&amp;&gt;. C=
ertainly it&#39;s the same general idea.</span></div><div><span style=3D"fo=
nt-family:arial,sans-serif;font-size:13px">I agree.</span></div></div><div =
class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Nov 13, 2014 a=
t 10:23 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D"mailto:mw_tria=
d@users.sourceforge.net" target=3D"_blank">mw_triad@users.sourceforge.net</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On =
2014-11-12 21:31, Brent Friedman wrote:<br>
&gt;&gt; It doesn&#39;t assume that the iterators are pointers, if that&#39=
;s what you<br>
&gt;&gt; mean.<br>
&gt;<br>
&gt; It assumes that it is possible to convert from nullptr_t to<br>
&gt; decltype(&amp;range.begin()).<br>
<br>
</span>Oops, yes, there is a &#39;*&#39; missing: &#39;decltype(&amp;*range=
..begin())&#39; (or<br>
std::addressof as Benjamin suggested). This should be obvious<br>
considering the RHS of the &#39;return&#39;.<br>
<br>
I am confused; I am not returning the iterator. I am returning the<br>
address of the iterator&#39;s value. While I would believe that might not b=
e<br>
possible in all cases, I don&#39;t see how it relates to the cases you are<=
br>
concerned about. (Also, my C++11-fu is not that strong; there may be a<br>
way to return the iterator value as a form of reference that would<br>
bypass these issues also.)<br>
<span class=3D""><br>
On 2014-11-12 21:52, Brent Friedman wrote:<br>
&gt; A function like first_or_null which returns an optional&lt;T&amp;&gt; =
could probably<br>
&gt; work alright for our purposes with only a bit of extra syntax over thi=
s<br>
&gt; range-if idea.<br>
<br>
</span>Brent, that&#39;s basically *what I wrote*, except using T* rather t=
han<br>
optional&lt;T&amp;&gt;. Certainly it&#39;s the same general idea.<br>
<span class=3D""><br>
&gt; It also assumes that this value constructed from nullptr necessarily<b=
r>
&gt; represents an invalid value (converts to false) for that iterator type=
..<br>
<br>
</span>Huh? The check is on begin =3D=3D end. No other assumptions are made=
 about<br>
the behavior of begin except that operator=3D=3D(end) will return true if<b=
r>
the range is not valid. Since AFAIUI this is how range-based for also<br>
works, if this assumption is being violated I&#39;d think you&#39;d have ot=
her<br>
problems...<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</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 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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a113dd29c7f9ce60507c0e93d--

.

On 2014-11-13 12:33, Brent Friedman wrote:
> I believe I was misinterpreting your intent. I had interpreted &begin() as
> a *begin() typo, not a &*begin() typo.

Ah... yeah, that could cause our confusion :-).

> If the intent is to return pointer-to-dereferenced-value, then that
> creates a separate issue. If *begin() returns say int (rather than
> int&) then that would return pointer-to-temporary-on-the-stack.

Right, that would be what I was getting at ("might not be possible in
all cases") in the previous message.

To be fair, I actually somewhat like your idea (I might even use it in
my own code if it was available; I have that "itching sensation" that
I've written code before where I could have used it), but I've seen how
language changes generally have a very high bar to pass. Unfortunately,
convenient or not, my impression is that this doesn't have a very good
chance of being accepted.

The bar tends to be lower where a library solution exists (and of
course, you can write and use the library solution yourself), which is
partly why I was exploring that. (For that matter, maybe your use
doesn't run afoul of the above issue...)

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

.