------=_Part_243_376730565.1448889061751
Content-Type: multipart/alternative;
 boundary="----=_Part_244_647611034.1448889061751"

------=_Part_244_647611034.1448889061751
Content-Type: text/plain; charset=UTF-8

Hi,

with optional<T> being part of the standard library, are there any plans to
make use of it in standard library components? One specific example that I
am thinking of is to deprecate the std::basic_string::find* functions that
return npos when nothing is found, and replace them with functions
returning optional<size_t>.

Best wishes,
  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/.

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

<div dir=3D"ltr">Hi,<br><br>with<code> optional&lt;T&gt; being part of the =
standard library, are there any plans to make use of it in standard library=
 components? One specific example that I am thinking of is to deprecate the=
 std::basic_string::find* functions that return npos when nothing is found,=
 and replace them with functions returning optional&lt;size_t&gt;.<br><br>B=
est wishes,<br>=C2=A0 Jens<br></code></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_244_647611034.1448889061751--
------=_Part_243_376730565.1448889061751--

.

> with optional<T> being part of the standard library, are there any
> plans to make use of it in standard library components? One specific
> example that I am thinking of is to deprecate the
> std::basic_string::find* functions that return npos when nothing is
> found, and replace them with functions returning optional<size_t>.

Or the return value of `std::map::insert`.

    http://en.cppreference.com/w/cpp/container/map/insert

I can never remember what to do with that result.

But since we cannot overload on return types, this would be a
(needless?) breaking change, unless we introduce new function names like
`maybe_insert`.


  Moritz

--

---
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_408_22593868.1448891185393
Content-Type: multipart/alternative;
 boundary="----=_Part_409_1403893048.1448891185394"

------=_Part_409_1403893048.1448891185394
Content-Type: text/plain; charset=UTF-8



Am Montag, 30. November 2015 14:37:26 UTC+1 schrieb Moritz Klammler:
>
> > with optional<T> being part of the standard library, are there any
> > plans to make use of it in standard library components? One specific
> > example that I am thinking of is to deprecate the
> > std::basic_string::find* functions that return npos when nothing is
> > found, and replace them with functions returning optional<size_t>.
>
> Or the return value of `std::map::insert`.
>
>     http://en.cppreference.com/w/cpp/container/map/insert

I don't think this qualifies as a good candidate, because the extra bool
gives some additional information. It will always return an iterator, but I
know if the element was previously already in the map. I don't think
optional covers that.

>
> But since we cannot overload on return types, this would be a
> (needless?) breaking change, unless we introduce new function names like
> `maybe_insert`.
>
For std::string, it could be possible to define free functions in std
namespace and mark the ones in the class as deprecated. This would also
improve the flat string interface a little bit.

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

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

<br><br>Am Montag, 30. November 2015 14:37:26 UTC+1 schrieb Moritz Klammler=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">&gt; with optional&lt;T&gt; b=
eing part of the standard library, are there any
<br>&gt; plans to make use of it in standard library components? One specif=
ic
<br>&gt; example that I am thinking of is to deprecate the
<br>&gt; std::basic_string::find* functions that return npos when nothing i=
s
<br>&gt; found, and replace them with functions returning optional&lt;size_=
t&gt;.
<br>
<br>Or the return value of `std::map::insert`.
<br>
<br>=C2=A0 =C2=A0 <a href=3D"http://en.cppreference.com/w/cpp/container/map=
/insert" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2=
Fcontainer%2Fmap%2Finsert\46sa\75D\46sntz\0751\46usg\75AFQjCNFV52lHRGesM5qb=
TUnh7uVp8y0rNg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.go=
ogle.com/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcontainer%2Fm=
ap%2Finsert\46sa\75D\46sntz\0751\46usg\75AFQjCNFV52lHRGesM5qbTUnh7uVp8y0rNg=
&#39;;return true;">http://en.cppreference.com/w/<wbr>cpp/container/map/ins=
ert</a></blockquote><div>I don&#39;t think this qualifies as a good candida=
te, because the extra bool gives some additional information. It will alway=
s return an iterator, but I know if the element was previously already in t=
he map. I don&#39;t think optional covers that.<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
<br>But since we cannot overload on return types, this would be a
<br>(needless?) breaking change, unless we introduce new function names lik=
e
<br>`maybe_insert`.
<br></blockquote><div>For std::string, it could be possible to define free =
functions in std namespace and mark the ones in the class as deprecated. Th=
is would also improve the flat string interface a little bit.<br><br>Cheers=
,<br>=C2=A0Jens<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 />

------=_Part_409_1403893048.1448891185394--
------=_Part_408_22593868.1448891185393--

.

>>> with optional<T> being part of the standard library, are there any
>>> plans to make use of it in standard library components? One
>> specific
>>> example that I am thinking of is to deprecate the
>>> std::basic_string::find* functions that return npos when nothing
>> is
>>> found, and replace them with functions returning optional<size_t>.
>>
>> [...]
> For std::string, it could be possible to define free functions in std
> namespace and mark the ones in the class as deprecated. This would
> also improve the flat string interface a little bit.

When using optional as a return type, the currently implemented
behavior
would be 'undefined behavior' if the optional does not contain a value.

Although, this is motivated by a gain of performance [1], this has the
consequences
that one normaly (?) has to check whether there is a value present or
not:

//////////////////////////////////
std::string haystack_without_needle = "##########";
std::string needle;

auto optional_position = haystack_without_needle.try_find(needle);

if (optional_position) {
   // access optional_position*
}
//////////////////////////////////

Any code like the following might result in undefined behavior:

//////////////////////////////////
std::string haystack_without_needle = "##########";
std::string needle;

auto position = haystack_without_needle.try_find(needle);

std::cout << "Found needle at: " << position* :: std::endl;
//////////////////////////////////

If there are functions introduced into the standard library, I'd favor
some clear naming in the
sense of try_find or maybe_find (though I would prefer the former) to
underline that one has to
check for a return value before use.

r.
--

[1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3672.html#rationale.access

--

---
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_13427_770852527.1448896757704
Content-Type: multipart/alternative;
 boundary="----=_Part_13428_160384090.1448896757705"

------=_Part_13428_160384090.1448896757705
Content-Type: text/plain; charset=UTF-8



On Monday, November 30, 2015 at 9:22:16 AM UTC-5, Robert Jakob wrote:
>
> >>> with optional<T> being part of the standard library, are there any
> >>> plans to make use of it in standard library components? One
> >> specific
> >>> example that I am thinking of is to deprecate the
> >>> std::basic_string::find* functions that return npos when nothing
> >> is
> >>> found, and replace them with functions returning optional<size_t>.
> >>
> >> [...]
> > For std::string, it could be possible to define free functions in std
> > namespace and mark the ones in the class as deprecated. This would
> > also improve the flat string interface a little bit.
>
> When using optional as a return type, the currently implemented
> behavior
> would be 'undefined behavior' if the optional does not contain a value.
>
> Although, this is motivated by a gain of performance [1], this has the
> consequences
> that one normaly (?) has to check whether there is a value present or
> not:
>
> //////////////////////////////////
> std::string haystack_without_needle = "##########";
> std::string needle;
>
> auto optional_position = haystack_without_needle.try_find(needle);
>
> if (optional_position) {
>    // access optional_position*
> }
> //////////////////////////////////
>
> Any code like the following might result in undefined behavior:
>
> //////////////////////////////////
> std::string haystack_without_needle = "##########";
> std::string needle;
>
> auto position = haystack_without_needle.try_find(needle);
>
> std::cout << "Found needle at: " << position* :: std::endl;
> //////////////////////////////////
>

I'll assume you meant `*position`.


> If there are functions introduced into the standard library, I'd favor
> some clear naming in the
> sense of try_find or maybe_find (though I would prefer the former) to
> underline that one has to
> check for a return value before use.
>

See, the problem with that is the implicit assumption that you *don't* have
to check with the *current* API. That you can use whatever value these
things return just fine. Which is not generally true.

If a function returns `npos`, how much use can you genuinely get out of it
without *knowing* that it returned `npos`? If the function was one of the
`find` functions, you really do have to know that it's `npos` before you
use it. You can't extract a substring or start getting characters from the
string or whatever unless you know that the value is a real index.

Oh sure, in a toy example where you're just printing out a value, it's
fine. But in a real example, where you do legitimate work? No, you have to
check.

`optional` just makes it clear that you *have to check*. That's a good
thing.

The only question is whether you want to return a larger value. Because
`optional<size_t`> will likely be 4 bytes larger than `size_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_13428_160384090.1448896757705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Monday, November 30, 2015 at 9:22:16 AM UTC-5, Robert Jakob wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">&gt;&gt;&gt; with optional&l=
t;T&gt; being part of the standard library, are there any
<br>&gt;&gt;&gt; plans to make use of it in standard library components? On=
e
<br>&gt;&gt; specific
<br>&gt;&gt;&gt; example that I am thinking of is to deprecate the
<br>&gt;&gt;&gt; std::basic_string::find* functions that return npos when n=
othing
<br>&gt;&gt; is
<br>&gt;&gt;&gt; found, and replace them with functions returning optional&=
lt;size_t&gt;.
<br>&gt;&gt;
<br>&gt;&gt; [...]
<br>&gt; For std::string, it could be possible to define free functions in =
std
<br>&gt; namespace and mark the ones in the class as deprecated. This would
<br>&gt; also improve the flat string interface a little bit.
<br>
<br>When using optional as a return type, the currently implemented=20
<br>behavior
<br>would be &#39;undefined behavior&#39; if the optional does not contain =
a value.
<br>
<br>Although, this is motivated by a gain of performance [1], this has the=
=20
<br>consequences
<br>that one normaly (?) has to check whether there is a value present or=
=20
<br>not:
<br>
<br>//////////////////////////////<wbr>////
<br>std::string haystack_without_needle =3D &quot;##########&quot;;
<br>std::string needle;
<br>
<br>auto optional_position =3D haystack_without_needle.try_<wbr>find(needle=
);
<br>
<br>if (optional_position) {
<br>=C2=A0 =C2=A0// access optional_position*
<br>}
<br>//////////////////////////////<wbr>////
<br>
<br>Any code like the following might result in undefined behavior:
<br>
<br>//////////////////////////////<wbr>////
<br>std::string haystack_without_needle =3D &quot;##########&quot;;
<br>std::string needle;
<br>
<br>auto position =3D haystack_without_needle.try_<wbr>find(needle);
<br>
<br>std::cout &lt;&lt; &quot;Found needle at: &quot; &lt;&lt; position* :: =
std::endl;
<br>//////////////////////////////<wbr>////
<br></blockquote><div><br>I&#39;ll assume you meant `*position`.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">
If there are functions introduced into the standard library, I&#39;d favor=
=20
<br>some clear naming in the
<br>sense of try_find or maybe_find (though I would prefer the former) to=
=20
<br>underline that one has to
<br>check for a return value before use.<br></blockquote><div><br>See, the =
problem with that is the implicit assumption that you <i>don&#39;t</i> have=
 to check with the <i>current</i> API. That you can use whatever value thes=
e things return just fine. Which is not generally true.<br><br>If a functio=
n returns `npos`, how much use can you genuinely get out of it without <i>k=
nowing</i> that it returned `npos`? If the function was one of the `find` f=
unctions, you really do have to know that it&#39;s `npos` before you use it=
.. You can&#39;t extract a substring or start getting characters from the st=
ring or whatever unless you know that the value is a real index.<br><br>Oh =
sure, in a toy example where you&#39;re just printing out a value, it&#39;s=
 fine. But in a real example, where you do legitimate work? No, you have to=
 check.<br><br>`optional` just makes it clear that you <i>have to check</i>=
.. That&#39;s a good thing.<br><br>The only question is whether you want to =
return a larger value. Because `optional&lt;size_t`&gt; will likely be 4 by=
tes larger than `size_t`.<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 />

------=_Part_13428_160384090.1448896757705--
------=_Part_13427_770852527.1448896757704--

.

------=_Part_375_401392276.1448897110468
Content-Type: multipart/alternative;
 boundary="----=_Part_376_1364166983.1448897110468"

------=_Part_376_1364166983.1448897110468
Content-Type: text/plain; charset=UTF-8

On Monday, November 30, 2015 at 8:46:25 AM UTC-5, jensa wrote:
>
> Am Montag, 30. November 2015 14:37:26 UTC+1 schrieb Moritz Klammler:
>>
>> > with optional<T> being part of the standard library, are there any
>> > plans to make use of it in standard library components? One specific
>> > example that I am thinking of is to deprecate the
>> > std::basic_string::find* functions that return npos when nothing is
>> > found, and replace them with functions returning optional<size_t>.
>>
>> Or the return value of `std::map::insert`.
>>
>>     http://en.cppreference.com/w/cpp/container/map/insert
>
> I don't think this qualifies as a good candidate, because the extra bool
> gives some additional information. It will always return an iterator, but I
> know if the element was previously already in the map. I don't think
> optional covers that.
>

Agreed.

Better candidates are all of the functions that return `end` iterators when
they mean "couldn't find it". So map::find, set::find, std::find in all its
forms, etc. In those cases, the `end` iterator only ever means "didn't find
it", and no user could ever actually use that iterator in some kind of
range process without checking for it.

--

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

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

On Monday, November 30, 2015 at 8:46:25 AM UTC-5, jensa wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">Am Montag, 30. November 2015 14:37:26 UTC+1=
 schrieb Moritz Klammler:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; with =
optional&lt;T&gt; being part of the standard library, are there any
<br>&gt; plans to make use of it in standard library components? One specif=
ic
<br>&gt; example that I am thinking of is to deprecate the
<br>&gt; std::basic_string::find* functions that return npos when nothing i=
s
<br>&gt; found, and replace them with functions returning optional&lt;size_=
t&gt;.
<br>
<br>Or the return value of `std::map::insert`.
<br>
<br>=C2=A0 =C2=A0 <a href=3D"http://en.cppreference.com/w/cpp/container/map=
/insert" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2=
Fcontainer%2Fmap%2Finsert\46sa\75D\46sntz\0751\46usg\75AFQjCNFV52lHRGesM5qb=
TUnh7uVp8y0rNg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.go=
ogle.com/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fcontainer%2Fm=
ap%2Finsert\46sa\75D\46sntz\0751\46usg\75AFQjCNFV52lHRGesM5qbTUnh7uVp8y0rNg=
&#39;;return true;">http://en.cppreference.com/w/<wbr>cpp/container/map/ins=
ert</a></blockquote><div>I don&#39;t think this qualifies as a good candida=
te, because the extra bool gives some additional information. It will alway=
s return an iterator, but I know if the element was previously already in t=
he map. I don&#39;t think optional covers that.<br></div></blockquote><div>=
<br>Agreed.<br><br>Better candidates are all of the functions that return `=
end` iterators when they mean &quot;couldn&#39;t find it&quot;. So map::fin=
d, set::find, std::find in all its forms, etc. In those cases, the `end` it=
erator only ever means &quot;didn&#39;t find it&quot;, and no user could ev=
er actually use that iterator in some kind of range process without checkin=
g for it.</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_376_1364166983.1448897110468--
------=_Part_375_401392276.1448897110468--

.

------=_Part_59_2002141349.1448897450493
Content-Type: multipart/alternative;
 boundary="----=_Part_60_276380175.1448897450493"

------=_Part_60_276380175.1448897450493
Content-Type: text/plain; charset=UTF-8



On Monday, November 30, 2015 at 8:11:02 AM UTC-5, jensa wrote:
>
> Hi,
>
> with optional<T> being part of the standard library,
>

It should be noted that `optional` is *not* part of the standard library.
It is part of the library fundamentals TS. I think that parts of that TS
have been voted into the standard library, but I'm pretty sure that, if
that's true, `optional` was not among them.


> are there any plans to make use of it in standard library components?
>

No such proposals currently exist.

--

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

<div dir=3D"ltr"><br><br>On Monday, November 30, 2015 at 8:11:02 AM UTC-5, =
jensa wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">H=
i,<br><br>with<code> optional&lt;T&gt; being part of the standard library,<=
/code></div></blockquote><div><br>It should be noted that `optional` is <i>=
not</i> part of the standard library. It is part of the library fundamental=
s TS. I think that parts of that TS have been voted into the standard libra=
ry, but I&#39;m pretty sure that, if that&#39;s true, `optional` was not am=
ong them.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><code> are there any plans to make use of it in standard librar=
y components?</code></div></blockquote><div><br>No such proposals currently=
 exist.</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_60_276380175.1448897450493--
------=_Part_59_2002141349.1448897450493--

.

On 2015-11-30 10:19, Nicol Bolas wrote:
> If a function returns `npos`, how much use can you genuinely get out of it
> without *knowing* that it returned `npos`?

Approximately real code:

  auto i = s.find(sep);
  process(s.substr(0, i);
  if (i != npos)
    process(s.substr(i+sep.size(), npos)

(...except the real code uses QString. Same general idea, though;
because the "not found" result is also the magic "everything" value, it
*is* possible to use it unchecked for certain operations.)

I somewhat hate to say it, because I otherwise liked the idea, but...
returning an optional would actually make the above code worse. (I'd
have to write 3 calls to process instead of 2, or else use a ?: or
value_or in the argument list to the first call.)

--
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_664_305304092.1448899088140
Content-Type: multipart/alternative;
 boundary="----=_Part_665_1811642577.1448899088140"

------=_Part_665_1811642577.1448899088140
Content-Type: text/plain; charset=UTF-8



On Monday, November 30, 2015 at 10:51:37 AM UTC-5, Matthew Woehlke wrote:
>
> On 2015-11-30 10:19, Nicol Bolas wrote:
> > If a function returns `npos`, how much use can you genuinely get out of
> it
> > without *knowing* that it returned `npos`?
>
> Approximately real code:
>
>   auto i = s.find(sep);
>   process(s.substr(0, i);
>   if (i != npos)
>     process(s.substr(i+sep.size(), npos)
>
> (...except the real code uses QString. Same general idea, though;
> because the "not found" result is also the magic "everything" value, it
> *is* possible to use it unchecked for certain operations.)
>
> I somewhat hate to say it, because I otherwise liked the idea, but...
> returning an optional would actually make the above code worse. (I'd
> have to write 3 calls to process instead of 2, or else use a ?: or
> value_or in the argument list to the first call.)
>

All you need to do is allow `substr` to take an `optional<size_t>`, and the
code works just fine:

auto opt = find(s, sep);
process(substr(s, 0, opt));
if(opt)
  process(substr(s, sep.size() + *opt, nullopt));

Indeed, every `basic_string` function that takes a length which could be
`npos` can be converted to using `optional<size_t>` instead.

--

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

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

<br><br>On Monday, November 30, 2015 at 10:51:37 AM UTC-5, Matthew Woehlke =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-11-30 10:19, Nic=
ol Bolas wrote:
<br>&gt; If a function returns `npos`, how much use can you genuinely get o=
ut of it=20
<br>&gt; without *knowing* that it returned `npos`?
<br>
<br>Approximately real code:
<br>
<br>=C2=A0 auto i =3D s.find(sep);
<br>=C2=A0 process(s.substr(0, i);
<br>=C2=A0 if (i !=3D npos)
<br>=C2=A0 =C2=A0 process(s.substr(i+sep.size(), npos)
<br>
<br>(...except the real code uses QString. Same general idea, though;
<br>because the &quot;not found&quot; result is also the magic &quot;everyt=
hing&quot; value, it
<br>*is* possible to use it unchecked for certain operations.)
<br>
<br>I somewhat hate to say it, because I otherwise liked the idea, but...
<br>returning an optional would actually make the above code worse. (I&#39;=
d
<br>have to write 3 calls to process instead of 2, or else use a ?: or
<br>value_or in the argument list to the first call.)
<br></blockquote><div><br>All you need to do is allow `substr` to take an `=
optional&lt;size_t&gt;`, and the code works just fine:<br><br><div class=3D=
"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: =
rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: brea=
k-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> opt </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> find</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">s</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 sep</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>process</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">substr</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">s</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> op=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">opt</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 process</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">substr</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">s</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> sep</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">size</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">opt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> nullopt</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span></div=
></code></div><br>Indeed, every `basic_string` function that takes a length=
 which could be `npos` can be converted to using `optional&lt;size_t&gt;` i=
nstead.<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 />

------=_Part_665_1811642577.1448899088140--
------=_Part_664_305304092.1448899088140--

.

Le 30/11/2015 14:11, jensa a =C3=A9crit :
> Hi,
>
> with optional<T> being part of the standard library, are there any plans =
to
> make use of it in standard library components? One specific example that =
I
> am thinking of is to deprecate the std::basic_string::find* functions tha=
t
> return npos when nothing is found, and replace them with functions
> returning optional<size_t>.
>
>
Not that I know.

If you are interested, I would suggest to propose algorithms that work=20
with string and string_view.
Once we have an alternative, we could propose to deprecate these member=20
function (if absolutely needed).

BTW, what would you propose as signature for the find algorithm?

Vicente

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

.