------=_Part_3137_1691763150.1410419208738
Content-Type: text/plain; charset=UTF-8

Alright, one more and I'm done for the day.

I think we're missing std::as_range from the library which (if I understand
correctly) was half-proposed by Alisdair Meredith after the removal of
begin/end for std::pair<Iterator, Iterator>. Aside from other utilities, it
dawns on me that this would make accessing map-like types much easier
(assuming that they all have equal_range; even non-multi-key versions) via
the idiom:

  for (auto& result : as_range(map.equal_range(key)))
    { /* ... */ }

Notably, that gracefully handles no results (key not found), one result,
and many results (for multimap-variants) without all the ugly "if
(result_iter != end)" baggage. Though I would find a new member (or STL
algorithm) with a slightly clearer and less redundant name better, e.g.

  for (auto& result : map.find_range(key))
    { /* ... */ }

Back on point: as_range, do we still want it?

(I don't think this is the same domain of issues that the Ranges SG/list is
dealing with.)

--

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

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

<div dir=3D"ltr">Alright, one more and I'm done for the day.<div><br></div>=
<div>I think we're missing std::as_range from the library which (if I under=
stand correctly) was half-proposed by Alisdair Meredith after the removal o=
f begin/end for std::pair&lt;Iterator, Iterator&gt;. Aside from other utili=
ties, it dawns on me that this would make accessing map-like types much eas=
ier (assuming that they all have equal_range; even non-multi-key versions) =
via the idiom:</div><div><br></div><div>&nbsp; for (auto&amp; result : as_r=
ange(map.equal_range(key)))</div><div>&nbsp; &nbsp; { /* ... */ }</div><div=
><br></div><div>Notably, that gracefully handles no results (key not found)=
, one result, and many results (for multimap-variants) without all the ugly=
 "if (result_iter !=3D end)" baggage. Though I would find a new member (or =
STL algorithm) with a slightly clearer and less redundant name better, e.g.=
</div><div><br></div><div>&nbsp; for (auto&amp; result : map.find_range(key=
))</div><div>&nbsp; &nbsp; { /* ... */ }<br></div><div><br></div><div>Back =
on point: as_range, do we still want it?<br></div><div><br></div><div>(I do=
n't think this is the same domain of issues that the Ranges SG/list is deal=
ing with.)</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_3137_1691763150.1410419208738--

.