------=_Part_17_10912716.1378910866664
Content-Type: text/plain; charset=ISO-8859-1

In
https://groups.google.com/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpYit was suggested to add two overloads, one that throws an exception and one
that takes an error_code.
I think this is the wrong solution, there should only be one overload that
returns optional<ip::address_v4>. That way the user can decide if an
invalid address should throw an exception (dereference, exception if
nullopt) or not (explicit checking).

--

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

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

<div dir=3D"ltr">In <a href=3D"https://groups.google.com/a/isocpp.org/forum=
/#!topic/networking/PxlTZQysMpY">https://groups.google.com/a/isocpp.org/for=
um/#!topic/networking/PxlTZQysMpY</a> it was suggested to add two overloads=
, one that throws an exception and one that takes an error_code.<br>I think=
 this is the wrong solution, there should only be one overload that returns=
 optional&lt;ip::address_v4&gt;. That way the user can decide if an invalid=
 address should throw an exception (dereference, exception if nullopt) or n=
ot (explicit checking).<br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_17_10912716.1378910866664--

.

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

On 11 September 2013 09:47, <stackmachine@hotmail.com> wrote:

> In
> https://groups.google.com/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpYit was suggested to add two overloads, one that throws an exception and one
> that takes an error_code.
> I think this is the wrong solution, there should only be one overload that
> returns optional<ip::address_v4>. That way the user can decide if an
> invalid address should throw an exception (dereference, exception if
> nullopt) or not (explicit checking).
>

Dereferencing a disengaged optional is undefined behavior.

IMO optional is not the right model here, because from_string is failing
due to bad input and not because the intention is to only sometimes return
an ip address.

I'm also not sure why this discussion is in std::proposals, as I don't see
a proposal here beyond what SG4 is working on.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 11 September 2013 09:47,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:stackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail=
..com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>In <a href=3D"https://groups.google.com=
/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpY" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpY</a> =
it was suggested to add two overloads, one that throws an exception and one=
 that takes an error_code.<br>

I think this is the wrong solution, there should only be one overload that =
returns optional&lt;ip::address_v4&gt;. That way the user can decide if an =
invalid address should throw an exception (dereference, exception if nullop=
t) or not (explicit checking).<span class=3D"HOEnZb"></span> <br>

</div></blockquote><div><br></div><div>Dereferencing a disengaged optional =
is undefined behavior.<br><br></div><div>IMO optional is not the right mode=
l here, because from_string is failing due to bad input and not because the=
 intention is to only sometimes return an ip address.<br clear=3D"all">

</div></div><br></div><div class=3D"gmail_extra">I&#39;m also not sure why =
this discussion is in std::proposals, as I don&#39;t see a proposal here be=
yond what SG4 is working on.<br></div><div class=3D"gmail_extra">-- <br>=A0=
Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverl=
ord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2a30a60abb304e61d0af0--

.

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

2013/9/11 <stackmachine@hotmail.com>

> In
> https://groups.google.com/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpYit was suggested to add two overloads, one that throws an exception and one
> that takes an error_code.
> I think this is the wrong solution, there should only be one overload that
> returns optional<ip::address_v4>. That way the user can decide if an
> invalid address should throw an exception (dereference, exception if
> nullopt) or not (explicit checking).
>

I disagree with that alternative for two reasons:

1) The filesystem proposal (accepted for the next TR) has introduced this
already popular idiom and the standard should try to keep consistent with
such idioms

2) Your replacement looses information, because you have no single
information about the reason of the failure after you found out that there
is no content. This is solved in the error_code approach, because the
error_code provides the corresponding information.

- Daniel

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/9/11  <span dir=3D"ltr">&lt;<a href=3D"mailto:stackmachine@hotmail.com" ta=
rget=3D"_blank">stackmachine@hotmail.com</a>&gt;</span><br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">
<div dir=3D"ltr">In <a href=3D"https://groups.google.com/a/isocpp.org/forum=
/#!topic/networking/PxlTZQysMpY" target=3D"_blank">https://groups.google.co=
m/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpY</a> it was suggested to=
 add two overloads, one that throws an exception and one that takes an erro=
r_code.<br>
I think this is the wrong solution, there should only be one overload that =
returns optional&lt;ip::address_v4&gt;. That way the user can decide if an =
invalid address should throw an exception (dereference, exception if nullop=
t) or not (explicit checking).<span class=3D"HOEnZb"><font color=3D"#888888=
"><br>
</font></span></div></blockquote><div><br></div></div>I disagree with that =
alternative for two reasons:<br><br></div><div class=3D"gmail_extra">1) The=
 filesystem proposal (accepted for the next TR) has introduced this already=
 popular idiom and the standard should try to keep consistent with such idi=
oms<br>
<br></div><div class=3D"gmail_extra">2) Your replacement looses information=
, because you have no single information about the reason of the failure af=
ter you found out that there is no content. This is solved in the error_cod=
e approach, because the error_code provides the corresponding information.<=
br>
<br></div><div class=3D"gmail_extra">- Daniel<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--f46d043890ed0cff9204e61d0d03--

.

------=_Part_177_11713605.1378914030217
Content-Type: text/plain; charset=ISO-8859-1



Am Mittwoch, 11. September 2013 17:11:09 UTC+2 schrieb Nevin ":-)" Liber:
>
> On 11 September 2013 09:47, <stackm...@hotmail.com <javascript:>> wrote:
>
>> In
>> https://groups.google.com/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpYit was suggested to add two overloads, one that throws an exception and one
>> that takes an error_code.
>> I think this is the wrong solution, there should only be one overload
>> that returns optional<ip::address_v4>. That way the user can decide if an
>> invalid address should throw an exception (dereference, exception if
>> nullopt) or not (explicit checking).
>>
>
> Dereferencing a disengaged optional is undefined behavior.
>
Wow, that is extremely surprising to me, seems almost like a defect in the
specification of std::optional. You made it extremely easy to use
std::optional wrongly. The semantics of operator * and .value() should be
swapped, value() should be renamed to something like unchecked_value() or
unchecked_get.


> IMO optional is not the right model here, because from_string is failing
> due to bad input and not because the intention is to only sometimes return
> an ip address.
>
 Actually, the intention is to only sometimes return an ip address. Because
if it wasn't, calling the function with an invalid address should be UB.
But it isn't, it's specified to return 0.0.0.0, which by the way is as
useful as the POSIX inet_addr function. (read: completely useless)


> I'm also not sure why this discussion is in std::proposals, as I don't see
> a proposal here beyond what SG4 is working on.
>
Because SG4 is not open to anyone and i think this is a valid concern.

--

---
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_177_11713605.1378914030217
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Am Mittwoch, 11. September 2013 17:11:09 UTC+2 sch=
rieb Nevin ":-)" Liber:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">On 11 September 2013 09:47,  <span dir=3D"ltr">&lt;<a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"n4vo8FXO9SsJ">stackm..=
..@hotmail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>In <a href=3D"https://groups.google.com=
/a/isocpp.org/forum/#!topic/networking/PxlTZQysMpY" target=3D"_blank">https=
://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/<wbr>networking/PxlTZQ=
ysMpY</a> it was suggested to add two overloads, one that throws an excepti=
on and one that takes an error_code.<br>

I think this is the wrong solution, there should only be one overload that =
returns optional&lt;ip::address_v4&gt;. That way the user can decide if an =
invalid address should throw an exception (dereference, exception if nullop=
t) or not (explicit checking).<span></span> <br>

</div></blockquote><div><br></div><div>Dereferencing a disengaged optional =
is undefined behavior.<br></div></div></div></div></blockquote><div>Wow, th=
at is extremely surprising to me, seems almost like a defect in the specifi=
cation of std::optional. You made it extremely easy to use std::optional wr=
ongly. The semantics of operator * and .value() should be swapped, value() =
should be renamed to something like unchecked_value() or unchecked_get. <br=
></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div>IMO optional is not the rig=
ht model here, because from_string is failing due to bad input and not beca=
use the intention is to only sometimes return an ip address.<br clear=3D"al=
l"></div></div></div></div></blockquote><div>&nbsp;Actually, the intention =
is to only sometimes return an ip address. Because if it wasn't, calling th=
e function with an invalid address should be UB. But it isn't, it's specifi=
ed to return 0.0.0.0, which by the way is as useful as the POSIX inet_addr =
function. (read: completely useless)<br></div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_=
quote"><div>

</div></div></div><div>I'm also not sure why this discussion is in std::pro=
posals, as I don't see a proposal here beyond what SG4 is working on.<br></=
div></div></blockquote><div>Because SG4 is not open to anyone and i think t=
his is a valid concern.<br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_177_11713605.1378914030217--

.

------=_Part_402_5062195.1378914382521
Content-Type: text/plain; charset=ISO-8859-1


>
> 2) Your replacement looses information, because you have no single
> information about the reason of the failure after you found out that there
> is no content. This is solved in the error_code approach, because the
> error_code provides the corresponding information.
>
What kind of information is lost? Either the string contains a valid IP
address, or it doesn'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_402_5062195.1378914382521
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>2) Your replacement looses information, because you have no single=
 information about the reason of the failure after you found out that there=
 is no content. This is solved in the error_code approach, because the erro=
r_code provides the corresponding information.</div></div></blockquote><div=
>What kind of information is lost? Either the string contains a valid IP ad=
dress, or it doesn't. <br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_402_5062195.1378914382521--

.

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

> Dereferencing a disengaged optional is undefined behavior.
>>
> Wow, that is extremely surprising to me, seems almost like a defect in the
> specification of std::optional. You made it extremely easy to use
> std::optional wrongly. The semantics of operator * and .value() should be
> swapped, value() should be renamed to something like unchecked_value() or
> unchecked_get.
>
>

No, it makes perfect sense. It's similar to operator[] and .at() for
std::vector.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">


<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Dereferencing a disen=
gaged optional is undefined behavior.<br></div></div></div></div></blockquo=
te></div><div>Wow, that is extremely surprising to me, seems almost like a =
defect in the specification of std::optional. You made it extremely easy to=
 use std::optional wrongly. The semantics of operator * and .value() should=
 be swapped, value() should be renamed to something like unchecked_value() =
or unchecked_get. <br>


</div><div><div>=A0=A0</div></div></div></blockquote><div><br>No, it makes =
perfect sense. It&#39;s similar to operator[] and .at() for std::vector.<br=
></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--e89a8ff1c0246c4c1104e61d94e5--

.

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

On 11 September 2013 18:50, Maurice Bos <m-ou.se@m-ou.se> wrote:

>
> Dereferencing a disengaged optional is undefined behavior.
>>>
>> Wow, that is extremely surprising to me, seems almost like a defect in
>> the specification of std::optional. You made it extremely easy to use
>> std::optional wrongly. The semantics of operator * and .value() should be
>> swapped, value() should be renamed to something like unchecked_value() or
>> unchecked_get.
>>
>>
>
> No, it makes perfect sense. It's similar to operator[] and .at() for
> std::vector.
>
>
>
>
And even more similar to operator* and .get() for smart pointers. No
defect, completely intentional.

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 September 2013 18:50, Maurice Bos <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:m-ou.se@m-ou.se" target=3D"_blank">m-ou.se@m-ou.se</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote"><div class=3D"im"><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div dir=3D"ltr"><div><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"><div><div class=3D"gmail_quote"><div>Dereferencing a disen=
gaged optional is undefined behavior.<br></div></div></div></div></blockquo=
te></div><div>Wow, that is extremely surprising to me, seems almost like a =
defect in the specification of std::optional. You made it extremely easy to=
 use std::optional wrongly. The semantics of operator * and .value() should=
 be swapped, value() should be renamed to something like unchecked_value() =
or unchecked_get. <br>



</div><div><div>=A0=A0</div></div></div></blockquote></div><div><br>No, it =
makes perfect sense. It&#39;s similar to operator[] and .at() for std::vect=
or.<br></div></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

<br><br></div></div></blockquote><div><br></div><div>And even more similar =
to operator* and .get() for smart pointers. No defect, completely intention=
al. <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e013d1470e92a6804e61e11e2--

.

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

I believe the intent is to model a pointer. Dereferencing a null pointer is
undefined behavior.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Wed, Sep 11, 2013 at 9:25 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
>
>
> On 11 September 2013 18:50, Maurice Bos <m-ou.se@m-ou.se> wrote:
>
>>
>>  Dereferencing a disengaged optional is undefined behavior.
>>>>
>>> Wow, that is extremely surprising to me, seems almost like a defect in
>>> the specification of std::optional. You made it extremely easy to use
>>> std::optional wrongly. The semantics of operator * and .value() should be
>>> swapped, value() should be renamed to something like unchecked_value() or
>>> unchecked_get.
>>>
>>>
>>
>> No, it makes perfect sense. It's similar to operator[] and .at() for
>> std::vector.
>>
>>
>>
>>
> And even more similar to operator* and .get() for smart pointers. No
> defect, completely intentional.
>
>  --
>
> ---
> 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/.

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

<div dir=3D"ltr">I believe the intent is to model a pointer. Dereferencing =
a null pointer is undefined behavior.</div><div class=3D"gmail_extra"><br c=
lear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=
=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com=
/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Sep 11, 2013 at 9:25 AM, Ville V=
outilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.=
com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote"><div class=3D"im">On 11 September 2013 18:50, Maurice Bos <span dir=
=3D"ltr">&lt;<a href=3D"mailto:m-ou.se@m-ou.se" target=3D"_blank">m-ou.se@m=
-ou.se</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">

<div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid">
<div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-l=
eft-width:1px;border-left-style:solid">


<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>Dereferencing a disen=
gaged optional is undefined behavior.<br></div></div></div></div></blockquo=
te></div><div>Wow, that is extremely surprising to me, seems almost like a =
defect in the specification of std::optional. You made it extremely easy to=
 use std::optional wrongly. The semantics of operator * and .value() should=
 be swapped, value() should be renamed to something like unchecked_value() =
or unchecked_get. <br>





</div><div><div>=A0=A0</div></div></div></blockquote></div><div><br>No, it =
makes perfect sense. It&#39;s similar to operator[] and .at() for std::vect=
or.<br></div></div></div></div><div><div>

<p></p>

<br><br></div></div></blockquote><div><br></div></div><div>And even more si=
milar to operator* and .get() for smart pointers. No defect, completely int=
entional. <br></div></div><br></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">



<p></p>

-- <br>
=A0<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" 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 />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2a120c2834104e61e6449--

.

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

2013/9/11 <stackmachine@hotmail.com>
>
> But it isn't, it's specified to return 0.0.0.0, which by the way is as
> useful as the POSIX inet_addr function. (read: completely useless)
>

Christopher has changed the proposal - '0.0.0.0' (address_v4::any()) is not
returned

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/9/11  <span dir=3D"ltr">&lt;<a href=3D"mailto:stackmachine@hotmail.com" ta=
rget=3D"_blank">stackmachine@hotmail.com</a>&gt;</span><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<div dir=3D"ltr"><div>But it isn&#39;t, it&#39;s specified to return 0.0.0.=
0, which by the way is as useful as the POSIX inet_addr function. (read: co=
mpletely useless)<br></div></div></blockquote></div><br></div><div class=3D=
"gmail_extra">
Christopher has changed the proposal - &#39;0.0.0.0&#39; (address_v4::any()=
) is not returned</div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b10d04b583bfa04e61f4a3c--

.

------=_Part_1105_25007989.1379602091716
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wednesday, September 11, 2013 4:12:34 PM UTC+1, Daniel Kr=FCgler wrote:

> 2013/9/11 <stackm...@hotmail.com <javascript:>>
>
>> In=20
>> https://groups.google.com/a/isocpp.org/forum/#!topic/networking/PxlTZQys=
MpYit was suggested to add two overloads, one that throws an exception and =
one=20
>> that takes an error_code.
>> I think this is the wrong solution, there should only be one overload=20
>> that returns optional<ip::address_v4>. That way the user can decide if a=
n=20
>> invalid address should throw an exception (dereference, exception if=20
>> nullopt) or not (explicit checking).
>>
>
> I disagree with that alternative for two reasons:
>
> 1) The filesystem proposal (accepted for the next TR) has introduced this=
=20
> already popular idiom and the standard should try to keep consistent with=
=20
> such idioms
>

That's hideously wrong. We should fix what we can fix. Consistency is only=
=20
a good thing if it's consistently good. Consistently terrible is just=20
terrible. If filesystem is broken in this way, then we should hold it back=
=20
until it's not broken. Taking an error-code out parameter by reference and=
=20
then returning some useless value is broken.

--=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_1105_25007989.1379602091716
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, September 11, 2013 4:12:34 PM UTC+1, Daniel =
Kr=FCgler wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">2013/9/11  <span dir=3D"ltr">&lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"yNuxwe6lB=
4IJ">stackm...@hotmail.com</a>&gt;</span><br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>
<div dir=3D"ltr">In <a href=3D"https://groups.google.com/a/isocpp.org/forum=
/#!topic/networking/PxlTZQysMpY" target=3D"_blank">https://groups.google.co=
m/a/<wbr>isocpp.org/forum/#!topic/<wbr>networking/PxlTZQysMpY</a> it was su=
ggested to add two overloads, one that throws an exception and one that tak=
es an error_code.<br>
I think this is the wrong solution, there should only be one overload that =
returns optional&lt;ip::address_v4&gt;. That way the user can decide if an =
invalid address should throw an exception (dereference, exception if nullop=
t) or not (explicit checking).<span><font color=3D"#888888"><br>
</font></span></div></blockquote><div><br></div></div>I disagree with that =
alternative for two reasons:<br><br></div><div>1) The filesystem proposal (=
accepted for the next TR) has introduced this already popular idiom and the=
 standard should try to keep consistent with such idioms</div></div></block=
quote><div><br></div><div>That's hideously wrong. We should fix what we can=
 fix. Consistency is only a good thing if it's consistently good. Consisten=
tly terrible is just terrible. If filesystem is broken in this way, then we=
 should hold it back until it's not broken. Taking an error-code out parame=
ter by reference and then returning some useless value is broken.</div></di=
v>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1105_25007989.1379602091716--

.

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

On 19 September 2013 09:48, DeadMG <wolfeinstein@gmail.com> wrote:

> On Wednesday, September 11, 2013 4:12:34 PM UTC+1, Daniel Kr=FCgler wrote=
:
>
>> 2013/9/11 <stackm...@hotmail.com>
>>
>> In https://groups.google.com/a/**isocpp.org/forum/#!topic/**
>>> networking/PxlTZQysMpY<https://groups.google.com/a/isocpp.org/forum/#!t=
opic/networking/PxlTZQysMpY>it was suggested to add two overloads, one that=
 throws an exception and one
>>> that takes an error_code.
>>> I think this is the wrong solution, there should only be one overload
>>> that returns optional<ip::address_v4>. That way the user can decide if =
an
>>> invalid address should throw an exception (dereference, exception if
>>> nullopt) or not (explicit checking).
>>>
>>
>> I disagree with that alternative for two reasons:
>>
>> 1) The filesystem proposal (accepted for the next TR) has introduced thi=
s
>> already popular idiom and the standard should try to keep consistent wit=
h
>> such idioms
>>
>
> That's hideously wrong.
>

There are now too many negatives for my brain to parse...

How do you think these things should work?

Method 1:  Two methods; one which throws, the other which sets a passed in
error code.
Method 2:  Return an optional

or do you have something else in mind?
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

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

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

<div dir=3D"ltr">On 19 September 2013 09:48, DeadMG <span dir=3D"ltr">&lt;<=
a href=3D"mailto:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gma=
il.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, September 11,=
 2013 4:12:34 PM UTC+1, Daniel Kr=FCgler wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote">2013/9/11  <span dir=3D"lt=
r">&lt;<a>stackm...@hotmail.com</a>&gt;</span><div class=3D"im"><br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">


<div dir=3D"ltr">In <a href=3D"https://groups.google.com/a/isocpp.org/forum=
/#!topic/networking/PxlTZQysMpY" target=3D"_blank">https://groups.google.co=
m/a/<u></u>isocpp.org/forum/#!topic/<u></u>networking/PxlTZQysMpY</a> it wa=
s suggested to add two overloads, one that throws an exception and one that=
 takes an error_code.<br>


I think this is the wrong solution, there should only be one overload that =
returns optional&lt;ip::address_v4&gt;. That way the user can decide if an =
invalid address should throw an exception (dereference, exception if nullop=
t) or not (explicit checking).<span><font color=3D"#888888"><br>


</font></span></div></blockquote><div><br></div></div></div><div class=3D"i=
m">I disagree with that alternative for two reasons:<br><br></div></div><di=
v class=3D"im"><div>1) The filesystem proposal (accepted for the next TR) h=
as introduced this already popular idiom and the standard should try to kee=
p consistent with such idioms</div>

</div></div></blockquote><div><br></div><div>That&#39;s hideously wrong. </=
div></div></blockquote><div><br></div><div>There are now too many negatives=
 for my brain to parse...<br><br></div><div>How do you think these things s=
hould work?<br>

<br></div><div>Method 1:=A0 Two methods; one which throws, the other which =
sets a passed in error code.<br>Method 2:=A0 Return an optional<br></div><d=
iv><br></div><div>or do you have something else in mind?<br clear=3D"all"><=
/div>

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

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b5daca02eb25104e6bdcd29--

.

On Thu, Sep 19, 2013 at 10:58 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> How do you think these things should work?
>
> Method 1:  Two methods; one which throws, the other which sets a passed in
> error code.
> Method 2:  Return an optional
>
> or do you have something else in mind?

Instead of leaving operations free functions, make an context
object to hold an error code and move those operations as
methods.  If you want, you can add something like
..set_exceptions() as well.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

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

On 19 September 2013 10:10, Zhihao Yuan <zy@miator.net> wrote:

> On Thu, Sep 19, 2013 at 10:58 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > How do you think these things should work?
> >
> > Method 1:  Two methods; one which throws, the other which sets a passed
> in
> > error code.
> > Method 2:  Return an optional
> >
> > or do you have something else in mind?
>
> Instead of leaving operations free functions, make an context
> object to hold an error code and move those operations as
> methods.  If you want, you can add something like
> .set_exceptions() as well.
>

Could you show some pseudocode?  It doesn't sound particularly easy to use
as a caller, but I might not be getting it.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 19 September 2013 10:10, Zhihao Yuan <span dir=3D"ltr">=
&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<div class=3D"im">On Thu, Sep 19, 2013 at 10:58 AM, Nevin Liber &lt;<a href=
=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br=
>
&gt; How do you think these things should work?<br>
&gt;<br>
&gt; Method 1: =A0Two methods; one which throws, the other which sets a pas=
sed in<br>
&gt; error code.<br>
&gt; Method 2: =A0Return an optional<br>
&gt;<br>
&gt; or do you have something else in mind?<br>
<br>
</div>Instead of leaving operations free functions, make an context<br>
object to hold an error code and move those operations as<br>
methods. =A0If you want, you can add something like<br>
..set_exceptions() as well.<br></blockquote><div><br></div><div>Could you sh=
ow some pseudocode?=A0 It doesn&#39;t sound particularly easy to use as a c=
aller, but I might not be getting it. <br></div></div>-- <br>=A0Nevin &quot=
;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" ta=
rget=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2be1ee682e604e6be1775--

.

On Thu, Sep 19, 2013 at 11:19 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Could you show some pseudocode?  It doesn't sound particularly easy to use
> as a caller, but I might not be getting it.

Currently we have:

  filesystem::copy(from, to);  // throws

and

  filesystem::error_code ec;
  filesystem::copy(from, to, ec);

If there is an context object:

  filesystem::context ctx;
  // ctx.set_exceptions(...)
  ctx.copy(from, to);  // throws if configured so; returns reference to ctx,
                       // which is contextual converted to bool

At least, it made the syntax of invoking throw or non-throw
the same.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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 Thu, Sep 19, 2013 at 11:37 AM, Zhihao Yuan <zy@miator.net> wrote:
>   ctx.copy(from, to);  // throws if configured so; returns reference to ctx,
>                        // which is contextual converted to bool

Err, no, it still has to return void; because there are operations
returning other useful things.  So the caller side code reminds
the same since you can't do `if (ctx.copy(...))`.

If you want to save time to branch on exception configurations,
I have a further thought:

     filesystem::context<CONFIG | HERE> ctx;

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

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

On 19 September 2013 10:37, Zhihao Yuan <zy@miator.net> wrote:

>
>   filesystem::context ctx;
>   // ctx.set_exceptions(...)
>   ctx.copy(from, to);  // throws if configured so; returns reference to
> ctx,
>                        // which is contextual converted to bool
>

I really don't like this kind of modality.  For instance, iostreams tries
to do this, and it seriously interferes with both useability and reasoning
about the code as a reader.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 19 September 2013 10:37, Zhihao Yuan <span dir=3D"ltr">=
&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<br>
=A0 filesystem::context ctx;<br>
=A0 // ctx.set_exceptions(...)<br>
=A0 ctx.copy(from, to); =A0// throws if configured so; returns reference to=
 ctx,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// which is contextual conve=
rted to bool<br></blockquote><div><br></div><div>I really don&#39;t like th=
is kind of modality.=A0 For instance, iostreams tries to do this, and it se=
riously interferes with both useability and reasoning about the code as a r=
eader.<br>

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

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b62249a01b19904e6be815d--

.

------=_Part_0_1379606828650
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

+1 this is one of the most terrible things about iostreams; I'd hate to see=
 that replicated elsewhere.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Nevin Liber" <nevin@eviloverlord.com>
To: "std-proposals@isocpp.org" <std-proposals@isocpp.org>
Subject: [std-proposals] On ip::address_v4::from_string
Date: Thu, Sep 19, 2013 8:49 AM

On 19 September 2013 10:37, Zhihao Yuan <zy@miator.net> wrote:




=A0 filesystem::context ctx;

=A0 // ctx.set_exceptions(...)

=A0 ctx.copy(from, to); =A0// throws if configured so; returns reference to=
 ctx,

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// which is contextual conve=
rted to bool

I really don't like this kind of modality.=A0 For instance, iostreams tries=
 to do this, and it seriously interferes with both useability and reasoning=
 about the code as a reader.



--=20
=A0Nevin ":-)" Liber=A0 <mailto:nevin@eviloverlord.com>=A0 (847) 691-1404





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

--=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_0_1379606828650
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div style=3D"font-size: 12pt; font-family: Calibri,sans-serif;"><div>+1 th=
is is one of the most terrible things about iostreams; I'd hate to see that=
 replicated elsewhere.</div><div><br></div><div>Sent from a touchscreen. Pl=
ease excuse the brevity and tpyos.</div><br><div id=3D"htc_header">----- Re=
ply message -----<br>From: &quot;Nevin Liber&quot; &lt;nevin@eviloverlord.c=
om&gt;<br>To: &quot;std-proposals@isocpp.org&quot; &lt;std-proposals@isocpp=
..org&gt;<br>Subject: [std-proposals] On ip::address_v4::from_string<br>Date=
: Thu, Sep 19, 2013 8:49 AM</div></div><br><div dir=3D"ltr">On 19 September=
 2013 10:37, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.=
net" target=3D"_blank">zy@miator.net</a>&gt;</span> wrote:<br><div class=3D=
"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
=A0 filesystem::context ctx;<br>
=A0 // ctx.set_exceptions(...)<br>
=A0 ctx.copy(from, to); =A0// throws if configured so; returns reference to=
 ctx,<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// which is contextual conve=
rted to bool<br></blockquote><div><br></div><div>I really don&#39;t like th=
is kind of modality.=A0 For instance, iostreams tries to do this, and it se=
riously interferes with both useability and reasoning about the code as a r=
eader.<br>

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

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_0_1379606828650--


.

On Thu, Sep 19, 2013 at 11:49 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
> I really don't like this kind of modality.  For instance, iostreams tries to
> do this, and it seriously interferes with both useability and reasoning
> about the code as a reader.

Why we have to support the case without exception anyway?

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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 Thu, 19 Sep 2013 12:17:48 -0400, Zhihao Yuan <zy@miator.net> wrote:
> On Thu, Sep 19, 2013 at 11:49 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
>> I really don't like this kind of modality.  For instance, iostreams tries to
>> do this, and it seriously interferes with both useability and reasoning
>> about the code as a reader.
>
> Why we have to support the case without exception anyway?

Because exceptions aren't the solution for error reporting when you
expect the
caller to handle the error, exception is for the case when you expect
the caller
to forward the error to its own caller.  And for file system as for
ip::*from_string, I
expect the caller to handle the error often enough that we want to
gather for
that usage.

Yours,

--
Jean-Marc

--

---
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 Thu, Sep 19, 2013 at 11:49 AM, Nevin Liber <nevin@eviloverlord.com> wrote:
>>   filesystem::context ctx;
>>   // ctx.set_exceptions(...)
>>   ctx.copy(from, to);  // throws if configured so; returns reference to
>> ctx,
>>                        // which is contextual converted to bool
>
>
> I really don't like this kind of modality.  For instance, iostreams tries to
> do this, and it seriously interferes with both useability and reasoning
> about the code as a reader.

Reasoning?  You mean the throw and nothrow cases should have
different syntax from the caller side?  I don't think so, at least the
standard library does not agree.  If a user want to indicate a piece
of code won't throw, he/she can place a static_assert(noexcept(..));

This can be achieved with a compile time exception configuration:

  filesystem::context<NOTRHOW> ctx;
  static_assert(ctx.copy(from, to));

Easy to implement with a noexcept(noexcept(NOTHROW))
specification for each member functions.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

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

Yes, the throw and nothrow cases should have different syntax on the
caller's side. The caller ultimately decides if it wants throwing behavior
or not.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Thu, Sep 19, 2013 at 12:50 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Thu, Sep 19, 2013 at 11:49 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> >>   filesystem::context ctx;
> >>   // ctx.set_exceptions(...)
> >>   ctx.copy(from, to);  // throws if configured so; returns reference to
> >> ctx,
> >>                        // which is contextual converted to bool
> >
> >
> > I really don't like this kind of modality.  For instance, iostreams
> tries to
> > do this, and it seriously interferes with both useability and reasoning
> > about the code as a reader.
>
> Reasoning?  You mean the throw and nothrow cases should have
> different syntax from the caller side?  I don't think so, at least the
> standard library does not agree.  If a user want to indicate a piece
> of code won't throw, he/she can place a static_assert(noexcept(..));
>
> This can be achieved with a compile time exception configuration:
>
>   filesystem::context<NOTRHOW> ctx;
>   static_assert(ctx.copy(from, to));
>
> Easy to implement with a noexcept(noexcept(NOTHROW))
> specification for each member functions.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Yes, the throw and nothrow cases should have different syn=
tax on the caller&#39;s side. The caller ultimately decides if it wants thr=
owing behavior or not.</div><div class=3D"gmail_extra"><br clear=3D"all"><d=
iv>

<div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a href=3D"https://bitbuck=
et.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</a></d=
iv><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=
=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Sep 19, 2013 at 12:50 PM, Zhihao=
 Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_bla=
nk">zy@miator.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">

On Thu, Sep 19, 2013 at 11:49 AM, Nevin Liber &lt;<a href=3D"mailto:nevin@e=
viloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br>
&gt;&gt; =A0 filesystem::context ctx;<br>
&gt;&gt; =A0 // ctx.set_exceptions(...)<br>
&gt;&gt; =A0 ctx.copy(from, to); =A0// throws if configured so; returns ref=
erence to<br>
&gt;&gt; ctx,<br>
&gt;&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// which is context=
ual converted to bool<br>
&gt;<br>
&gt;<br>
&gt; I really don&#39;t like this kind of modality. =A0For instance, iostre=
ams tries to<br>
&gt; do this, and it seriously interferes with both useability and reasonin=
g<br>
&gt; about the code as a reader.<br>
<br>
Reasoning? =A0You mean the throw and nothrow cases should have<br>
different syntax from the caller side? =A0I don&#39;t think so, at least th=
e<br>
standard library does not agree. =A0If a user want to indicate a piece<br>
of code won&#39;t throw, he/she can place a static_assert(noexcept(..));<br=
>
<br>
This can be achieved with a compile time exception configuration:<br>
<br>
=A0 filesystem::context&lt;NOTRHOW&gt; ctx;<br>
=A0 static_assert(ctx.copy(from, to));<br>
<br>
Easy to implement with a noexcept(noexcept(NOTHROW))<br>
specification for each member functions.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<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 />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c20afca9fbc304e6c1ec3c--

.

On Thu, Sep 19, 2013 at 3:54 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> Yes, the throw and nothrow cases should have different syntax on the
> caller's side. The caller ultimately decides if it wants throwing behavior
> or not.

Even so, it's still possible with a context, because we only need
one context (which is no-op) for all the throwing case (errno is
thread-local, no worry).

  filesystem {
    template <bool>
    struct __context;  // configurable context

    typedef context __context<true>;  // nothrow context
    __context<false> fs;
  }

So the caller side of throwing:

  filesystem::fs.copy(from, to);  // or using filesystem::fs

caller side of nothrow:

  filesystem::context ctx;
  ctx.copy(from, to);

I don't think people define an stream named "cout", same as "fs".
Pick any short and distinct name as you like.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

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

I don't see how that is clearer.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Thu, Sep 19, 2013 at 1:01 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Thu, Sep 19, 2013 at 3:54 PM, Billy O'Neal <billy.oneal@gmail.com>
> wrote:
> > Yes, the throw and nothrow cases should have different syntax on the
> > caller's side. The caller ultimately decides if it wants throwing
> behavior
> > or not.
>
> Even so, it's still possible with a context, because we only need
> one context (which is no-op) for all the throwing case (errno is
> thread-local, no worry).
>
>   filesystem {
>     template <bool>
>     struct __context;  // configurable context
>
>     typedef context __context<true>;  // nothrow context
>     __context<false> fs;
>   }
>
> So the caller side of throwing:
>
>   filesystem::fs.copy(from, to);  // or using filesystem::fs
>
> caller side of nothrow:
>
>   filesystem::context ctx;
>   ctx.copy(from, to);
>
> I don't think people define an stream named "cout", same as "fs".
> Pick any short and distinct name as you like.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">I don&#39;t see how that is clearer.</div><div class=3D"gm=
ail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</d=
iv><div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">htt=
ps://github.com/BillyONeal/</a></div>

<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Sep 19, 2013 at 1:01 PM, Zhihao =
Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blan=
k">zy@miator.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">

<div class=3D"im">On Thu, Sep 19, 2013 at 3:54 PM, Billy O&#39;Neal &lt;<a =
href=3D"mailto:billy.oneal@gmail.com">billy.oneal@gmail.com</a>&gt; wrote:<=
br>
&gt; Yes, the throw and nothrow cases should have different syntax on the<b=
r>
&gt; caller&#39;s side. The caller ultimately decides if it wants throwing =
behavior<br>
&gt; or not.<br>
<br>
</div>Even so, it&#39;s still possible with a context, because we only need=
<br>
one context (which is no-op) for all the throwing case (errno is<br>
thread-local, no worry).<br>
<br>
=A0 filesystem {<br>
=A0 =A0 template &lt;bool&gt;<br>
=A0 =A0 struct __context; =A0// configurable context<br>
<br>
=A0 =A0 typedef context __context&lt;true&gt;; =A0// nothrow context<br>
=A0 =A0 __context&lt;false&gt; fs;<br>
=A0 }<br>
<br>
So the caller side of throwing:<br>
<br>
=A0 filesystem::fs.copy(from, to); =A0// or using filesystem::fs<br>
<br>
caller side of nothrow:<br>
<br>
=A0 filesystem::context ctx;<br>
=A0 ctx.copy(from, to);<br>
<br>
I don&#39;t think people define an stream named &quot;cout&quot;, same as &=
quot;fs&quot;.<br>
Pick any short and distinct name as you like.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<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>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b33d5a0f8083504e6c20e66--

.

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

On 19 September 2013 14:50, Zhihao Yuan <zy@miator.net> wrote:

>
> > I really don't like this kind of modality.  For instance, iostreams
> tries to
> > do this, and it seriously interferes with both useability and reasoning
> > about the code as a reader.
>
> Reasoning?


Using iostreams as an example, given the following piece of code:

cout << 11;

1)  What is the output?
2)  Can it throw?

I don't know how to answer either of those questions w/o looking at the
entire code base (and really, the run time logic flow) to see if it
modifies the context information which cout holds.

 You mean the throw and nothrow cases should have
> different syntax from the caller side?  I don't think so, at least the
> standard library does not agree.  If a user want to indicate a piece
> of code won't throw, he/she can place a static_assert(noexcept(..));
>

1.  Ugh.

2.  It isn't that I care if it throws; rather, I have to know how to handle
errors.  Having multiple error mechanisms makes generic code significantly
harder to write (as it has to either handle all error mechanisms).

Different syntax is significantly easier to use for the same benefit.  Why
bother templating something if it cannot be used in a generic way?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 19 September 2013 14:50, Zhihao Yuan <span dir=3D"ltr">=
&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<div class=3D"im"><br>
&gt; I really don&#39;t like this kind of modality. =A0For instance, iostre=
ams tries to<br>
&gt; do this, and it seriously interferes with both useability and reasonin=
g<br>
&gt; about the code as a reader.<br>
<br>
</div>Reasoning? </blockquote><div><br></div><div>Using iostreams as an exa=
mple, given the following piece of code:<br><br></div><div>cout &lt;&lt; 11=
;<br><br></div><div>1)=A0 What is the output?<br></div><div>2)=A0 Can it th=
row?<br>

</div><div><br></div><div>I don&#39;t know how to answer either of those qu=
estions w/o looking at the entire code base (and really, the run time logic=
 flow) to see if it modifies the context information which cout holds.<br>

<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">=A0You mean the throw and nothrow =
cases should have<br>
different syntax from the caller side? =A0I don&#39;t think so, at least th=
e<br>
standard library does not agree. =A0If a user want to indicate a piece<br>
of code won&#39;t throw, he/she can place a static_assert(noexcept(..));<br=
></blockquote><div><br></div><div>1.=A0 Ugh.<br><br></div><div>2.=A0 It isn=
&#39;t that I care if it throws; rather, I have to know how to handle error=
s.=A0 Having multiple error mechanisms makes generic code significantly har=
der to write (as it has to either handle all error mechanisms).<br>

<br></div><div>Different syntax is significantly easier to use for the same=
 benefit.=A0 Why bother templating something if it cannot be used in a gene=
ric way?<br></div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2ddb8b655d004e6c2250f--

.

On Thu, Sep 19, 2013 at 4:09 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Using iostreams as an example, given the following piece of code:
>
> cout << 11;
>
> 1)  What is the output?
> 2)  Can it throw?
>
> I don't know how to answer either of those questions w/o looking at the
> entire code base (and really, the run time logic flow) to see if it modifies
> the context information which cout holds.

I got it.  So my later post shows we can name them differently.
The global `fs` is an implementation-defined context, which throws.

  fs.copy(from, to);  // using filesystem::fs;

All the context user created does not throw:

  filesystem::context ctx;
  ctx.copy(from, to);

In this way, they are distinguished.

> 2.  It isn't that I care if it throws; rather, I have to know how to handle
> errors.  Having multiple error mechanisms makes generic code significantly
> harder to write (as it has to either handle all error mechanisms).
>
> Different syntax is significantly easier to use for the same benefit.  Why
> bother templating something if it cannot be used in a generic way?

I don't expect different error handling approaches can be
used in one template function in caller side, but, I don't
want to mess up the parameters with extra "error_code"
parameter.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

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

On 19 September 2013 15:16, Zhihao Yuan <zy@miator.net> wrote:

>
> I got it.  So my later post shows we can name them differently.
> The global `fs` is an implementation-defined context, which throws.
>
>   fs.copy(from, to);  // using filesystem::fs;
>
> All the context user created does not throw:
>
>   filesystem::context ctx;
>   ctx.copy(from, to);
>
> In this way, they are distinguished.
>

If two things have the same syntax, it is inevitable that people will
attempt to use them in a generic way.

If the context holds no state, why do we need it?

If the context holds state, we've moved the error mechanism from being
known at compile time to being determined at run time.  IMO, this is a bad
thing.

Either way, I don't want a context.


> I don't expect different error handling approaches can be
> used in one template function in caller side, but, I don't
> want to mess up the parameters with extra "error_code"
> parameter.
>

Then don't use those calls.

Exceptions are significantly harder (and far more expensive) to use for
common failure cases that need to be handled locally (i.e., at the call
site).  from_string() sometimes falls into this category, so having both a
non-throwing and throwing version is justified.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 19 September 2013 15:16, Zhihao Yuan <span dir=3D"ltr">=
&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<div class=3D"im"><br>
</div>I got it. =A0So my later post shows we can name them differently.<br>
The global `fs` is an implementation-defined context, which throws.<br>
<br>
=A0 fs.copy(from, to); =A0// using filesystem::fs;<br>
<br>
All the context user created does not throw:<br>
<div class=3D"im"><br>
=A0 filesystem::context ctx;<br>
=A0 ctx.copy(from, to);<br>
<br>
</div>In this way, they are distinguished.<br></blockquote><div><br></div><=
div>If two things have the same syntax, it is inevitable that people will a=
ttempt to use them in a generic way.<br><br></div><div>If the context holds=
 no state, why do we need it?<br>

<br></div><div>If the context holds state, we&#39;ve moved the error mechan=
ism from being known at compile time to being determined at run time.=A0 IM=
O, this is a bad thing.<br><br></div><div>Either way, I don&#39;t want a co=
ntext.<br>

</div><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">I don&#39;t expect different error handling approaches ca=
n be<br></div>
used in one template function in caller side, but, I don&#39;t<br>
want to mess up the parameters with extra &quot;error_code&quot;<br>
parameter.<br></blockquote><div><br></div><div>Then don&#39;t use those cal=
ls.<br><br>Exceptions are significantly harder (and far more expensive) to =
use for common failure cases that need to be handled locally (i.e., at the =
call site).=A0 from_string() sometimes falls into this category, so having =
both a non-throwing and throwing version is justified.<br>

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

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b62249adc7f2f04e6c2661d--

.

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

We could go the C# route and have do_something which returns the thing and
throws an exception on failure, and a separate try_do_something which
returns the result via an out parameter and returns an error_code.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Thu, Sep 19, 2013 at 1:28 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 19 September 2013 15:16, Zhihao Yuan <zy@miator.net> wrote:
>
>>
>> I got it.  So my later post shows we can name them differently.
>> The global `fs` is an implementation-defined context, which throws.
>>
>>   fs.copy(from, to);  // using filesystem::fs;
>>
>> All the context user created does not throw:
>>
>>   filesystem::context ctx;
>>   ctx.copy(from, to);
>>
>> In this way, they are distinguished.
>>
>
> If two things have the same syntax, it is inevitable that people will
> attempt to use them in a generic way.
>
> If the context holds no state, why do we need it?
>
> If the context holds state, we've moved the error mechanism from being
> known at compile time to being determined at run time.  IMO, this is a bad
> thing.
>
> Either way, I don't want a context.
>
>
>> I don't expect different error handling approaches can be
>> used in one template function in caller side, but, I don't
>> want to mess up the parameters with extra "error_code"
>> parameter.
>>
>
> Then don't use those calls.
>
> Exceptions are significantly harder (and far more expensive) to use for
> common failure cases that need to be handled locally (i.e., at the call
> site).  from_string() sometimes falls into this category, so having both a
> non-throwing and throwing version is justified.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div>We could go the C# route and have do_something which =
returns the thing and throws an exception on failure, and a separate try_do=
_something which returns the result via an out parameter and returns an err=
or_code.</div>

</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
 target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Sep 19, 2013 at 1:28 PM, Nevin L=
iber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">

<div dir=3D"ltr"><div class=3D"im">On 19 September 2013 15:16, Zhihao Yuan =
<span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy=
@miator.net</a>&gt;</span> wrote:<br></div><div class=3D"gmail_extra"><div =
class=3D"gmail_quote">

<div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-=
width:1px;border-left-style:solid">

<div><br>
</div>I got it. =A0So my later post shows we can name them differently.<br>
The global `fs` is an implementation-defined context, which throws.<br>
<br>
=A0 fs.copy(from, to); =A0// using filesystem::fs;<br>
<br>
All the context user created does not throw:<br>
<div><br>
=A0 filesystem::context ctx;<br>
=A0 ctx.copy(from, to);<br>
<br>
</div>In this way, they are distinguished.<br></blockquote><div><br></div><=
/div><div>If two things have the same syntax, it is inevitable that people =
will attempt to use them in a generic way.<br><br></div><div>If the context=
 holds no state, why do we need it?<br>



<br></div><div>If the context holds state, we&#39;ve moved the error mechan=
ism from being known at compile time to being determined at run time.=A0 IM=
O, this is a bad thing.<br><br></div><div>Either way, I don&#39;t want a co=
ntext.<br>



</div><div class=3D"im"><div>=A0<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid">
<div>I don&#39;t expect different error handling approaches can be<br></div=
>
used in one template function in caller side, but, I don&#39;t<br>
want to mess up the parameters with extra &quot;error_code&quot;<br>
parameter.<br></blockquote><div><br></div></div><div>Then don&#39;t use tho=
se calls.<br><br>Exceptions are significantly harder (and far more expensiv=
e) to use for common failure cases that need to be handled locally (i.e., a=
t the call site).=A0 from_string() sometimes falls into this category, so h=
aving both a non-throwing and throwing version is justified.<br>



</div></div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;=
mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@ev=
iloverlord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" target=3D"_b=
lank" value=3D"+18476911404">(847) 691-1404</a>
</div></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<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" 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 />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7b5d33d4649b9004e6c27253--

.

On Thu, Sep 19, 2013 at 4:28 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> If two things have the same syntax, it is inevitable that people will
> attempt to use them in a generic way.

They have different noexcept property.  People should care
about this in generic code, IMHO.

> If the context holds no state, why do we need it?

Because it's easy to implement... I don't need to have two copies
of function names, one for free functions, one for member functions.

OK, if you don't mind, we can do this:

  filesystem::copy(from, to);  // no context, free function, throws

  ctx.copy(from, to);  // with context, member function, nothrow

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
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_0_1379625509372
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline

That is functionally equivalent to having different function names. It adds no value over different function names.

Sent from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Zhihao Yuan" <zy@miator.net>
To: "std-proposals@isocpp.org" <std-proposals@isocpp.org>
Subject: [std-proposals] On ip::address_v4::from_string
Date: Thu, Sep 19, 2013 1:39 PM

On Thu, Sep 19, 2013 at 4:28 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> If two things have the same syntax, it is inevitable that people will
> attempt to use them in a generic way.

They have different noexcept property.  People should care
about this in generic code, IMHO.

> If the context holds no state, why do we need it?

Because it's easy to implement... I don't need to have two copies
of function names, one for free functions, one for member functions.

OK, if you don't mind, we can do this:

filesystem::copy(from, to);  // no context, free function, throws

ctx.copy(from, to);  // with context, member function, nothrow

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

--

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html><head></head><body><div style=3D"font-size: 12pt; font-family: Calibr=
i,sans-serif;"><div>That is functionally equivalent to having different fun=
ction names. It adds no value over different function names.</div><div><br>=
</div><div>Sent from a touchscreen. Please excuse the brevity and tpyos.</d=
iv><br><div id=3D"htc_header">----- Reply message -----<br>From: &quot;Zhih=
ao Yuan&quot; &lt;zy@miator.net&gt;<br>To: &quot;std-proposals@isocpp.org&q=
uot; &lt;std-proposals@isocpp.org&gt;<br>Subject: [std-proposals] On ip::ad=
dress_v4::from_string<br>Date: Thu, Sep 19, 2013 1:39 PM</div></div><br><pr=
e style=3D"word-wrap: break-word; white-space: pre-wrap;">On Thu, Sep 19, 2=
013 at 4:28 PM, Nevin Liber &lt;nevin@eviloverlord.com&gt; wrote:
&gt; If two things have the same syntax, it is inevitable that people will
&gt; attempt to use them in a generic way.

They have different noexcept property.  People should care
about this in generic code, IMHO.

&gt; If the context holds no state, why do we need it?

Because it's easy to implement... I don't need to have two copies
of function names, one for free functions, one for member functions.

OK, if you don't mind, we can do this:

  filesystem::copy(from, to);  // no context, free function, throws

  ctx.copy(from, to);  // with context, member function, nothrow

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- <a href=3D"http://4bsd.biz/">http://4bsd.biz/</a>

--=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 <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/.">http://groups.google.com/a/isocpp.org/group/std-proposals/=
..</a>
</pre></body></html>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_0_1379625509372--


.

On Thu, Sep 19, 2013 at 5:18 PM, billy.oneal@gmail.com
<billy.oneal@gmail.com> wrote:
> That is functionally equivalent to having different function names. It adds
> no value over different function names.

Syntax matters.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

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

On 19 September 2013 16:23, Zhihao Yuan <zy@miator.net> wrote:

> On Thu, Sep 19, 2013 at 5:18 PM, billy.oneal@gmail.com
> <billy.oneal@gmail.com> wrote:
> > That is functionally equivalent to having different function names. It
> adds
> > no value over different function names.
>
> Syntax matters.
>

I don't see anyone here disagreeing with that.

We just disagree with you on how to spell it.  I favor different overloads;
you favor templates, and still others favor different function names.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 19 September 2013 16:23, Zhihao Yuan <span dir=3D"ltr">=
&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<div class=3D"im">On Thu, Sep 19, 2013 at 5:18 PM, <a href=3D"mailto:billy.=
oneal@gmail.com">billy.oneal@gmail.com</a><br>
&lt;<a href=3D"mailto:billy.oneal@gmail.com">billy.oneal@gmail.com</a>&gt; =
wrote:<br>
&gt; That is functionally equivalent to having different function names. It=
 adds<br>
&gt; no value over different function names.<br>
<br>
</div>Syntax matters.<br></blockquote><div><br></div><div>I don&#39;t see a=
nyone here disagreeing with that.<br><br>We just disagree with you on how t=
o spell it.=A0 I favor different overloads; you favor templates, and still =
others favor different function names.<br>

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

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0158af4eca62a604e6c33f8c--

.

On Thu, Sep 19, 2013 at 5:28 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> We just disagree with you on how to spell it.  I favor different overloads;
> you favor templates, and still others favor different function names.

Overloads:

  copy(from, to);

  error_code ec;
  copy(from, to, ec);

Different names:

  copy(from, to);

  error_code ec;
  nothrow_copy(from, to, ec);  // ??

My suggestion:

  copy(from, to);

  context ctx;
  ctx.copy(from, to);

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

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

.

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

No, it would be different names:

copy(from, to); //throws

error_code ec = try_copy(from, to);

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Thu, Sep 19, 2013 at 2:39 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Thu, Sep 19, 2013 at 5:28 PM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
> > We just disagree with you on how to spell it.  I favor different
> overloads;
> > you favor templates, and still others favor different function names.
>
> Overloads:
>
>   copy(from, to);
>
>   error_code ec;
>   copy(from, to, ec);
>
> Different names:
>
>   copy(from, to);
>
>   error_code ec;
>   nothrow_copy(from, to, ec);  // ??
>
> My suggestion:
>
>   copy(from, to);
>
>   context ctx;
>   ctx.copy(from, to);
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div>No, it would be different names:</div><div>=A0</div><=
div>copy(from, to); //throws</div><div>=A0</div><div>error_code ec =3D try_=
copy(from, to);</div></div><div class=3D"gmail_extra"><br clear=3D"all"><di=
v><div dir=3D"ltr">

<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Sep 19, 2013 at 2:39 PM, Zhihao =
Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blan=
k">zy@miator.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">

<div class=3D"im">On Thu, Sep 19, 2013 at 5:28 PM, Nevin Liber &lt;<a href=
=3D"mailto:nevin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br=
>
</div><div class=3D"im">&gt; We just disagree with you on how to spell it. =
=A0I favor different overloads;<br>
&gt; you favor templates, and still others favor different function names.<=
br>
<br>
</div>Overloads:<br>
<br>
=A0 copy(from, to);<br>
<br>
=A0 error_code ec;<br>
=A0 copy(from, to, ec);<br>
<br>
Different names:<br>
<br>
=A0 copy(from, to);<br>
<br>
=A0 error_code ec;<br>
=A0 nothrow_copy(from, to, ec); =A0// ??<br>
<br>
My suggestion:<br>
<br>
=A0 copy(from, to);<br>
<br>
=A0 context ctx;<br>
=A0 ctx.copy(from, to);<br>
<div class=3D"im HOEnZb"><br>
--<br>
Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>
___________________________________________________<br>
4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/</a>=
<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<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 />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e013c701a4bdbcc04e6c46d9b--

.

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

On 19 September 2013 16:39, Zhihao Yuan <zy@miator.net> wrote:

>
> My suggestion:
>
>   copy(from, to);
>
>   context ctx;
>   ctx.copy(from, to);
>

So, you *still* want the error handling mechanism to be determined and
changeable at run time? Um, okay (although I would vote strongly against
such a thing), we can add "do as iostreams does" to the list.

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

--

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

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

<div dir=3D"ltr">On 19 September 2013 16:39, Zhihao Yuan <span dir=3D"ltr">=
&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt=
;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<br>
My suggestion:<br>
<br>
=A0 copy(from, to);<br>
<br>
=A0 context ctx;<br>
=A0 ctx.copy(from, to);<br></blockquote><div><br></div><div>So, you <i>stil=
l</i> want the error handling mechanism to be determined and changeable at =
run time? Um, okay (although I would vote strongly against such a thing), w=
e can add &quot;do as iostreams does&quot; to the list.<br clear=3D"all">

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

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bdc0934f6c1e604e6c45e09--

.

------=_Part_992_15826156.1379628922410
Content-Type: text/plain; charset=ISO-8859-1

No.

or do you have something else in mind?


Yep.

Here's the thing. It should be *impossible* for the user to access an
invalid value. std::optional doesn't really fit this bill partly because it
can't handle holding a failure object with information like an exception,
and partly because it offers unchecked accessors. So if the user has

auto a = from_string(stuff);

then either the following statements are never reached because an exception
was thrown, so we guarantee that "a" is always valid (any user code relying
on that assumption is never executed), or, a is some composite object that
only permits checked access to the T which is the valid result, and offers
an exception/error object if there is no object. std::optional does not
work here for reasons I outlined above.

Any suggestion that permits the user to access a result value that was not
actually parsed from the string, or permits UB on invalid input in any way,
is incorrect.

Of course, it's inherently obvious that no Standard class is appropriate
for non-exceptional error handling. So unless the networking guys want to
address this in it's entirety in their proposal, it would probably be
better if they would stick to exceptional errors only. The fact that the
Standard can't get this right sets a poor example for user code.

--

---
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_992_15826156.1379628922410
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">No.<div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: r=
gb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">or do you =
have something else in mind?</blockquote><div><br></div><div>Yep.</div><div=
><br></div><div>Here's the thing. It should be <i>impossible</i> for the us=
er to access an invalid value. std::optional doesn't really fit this bill p=
artly because it can't handle holding a failure object with information lik=
e an exception, and partly because it offers unchecked accessors. So if the=
 user has</div><div><br></div><div><div class=3D"prettyprint" style=3D"back=
ground-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); wor=
d-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><font color=3D"#=
000000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> from_str=
ing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">stuff</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span></font></div=
></code></div><div><br></div><div>then either the following statements are =
never reached because an exception was thrown, so we guarantee that "a" is =
always valid (any user code relying on that assumption is never executed), =
or, a is some composite object that only permits checked access to the T wh=
ich is the valid result, and offers an exception/error object if there is n=
o object. std::optional does not work here for reasons I outlined above.</d=
iv></div><div><br></div><div>Any suggestion that permits the user to access=
 a result value that was not actually parsed from the string, or permits UB=
 on invalid input in any way, is incorrect.</div><div><br></div><div>Of cou=
rse, it's inherently obvious that no Standard class is appropriate for non-=
exceptional error handling. So unless the networking guys want to address t=
his in it's entirety in their proposal, it would probably be better if they=
 would stick to exceptional errors only. The fact that the Standard can't g=
et this right sets a poor example for user code.</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_992_15826156.1379628922410--

.

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

On Sep 19, 2013 7:02 PM, "Nevin Liber" <nevin@eviloverlord.com> wrote:
>>   copy(from, to);
>>
>>   context ctx;
>>   ctx.copy(from, to);
>
>
> So, you still want the error handling mechanism to be determined and
changeable at run time? Um, okay (although I would vote strongly against
such a thing), we can add "do as iostreams does" to the list.

My suggestion stops using runtime mechanisms long time ago.  The current
version is, the free function one throws, the one with context does not.
Imagine moving the error_code argument as the object, just they have
different types.

--

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

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

<p>On Sep 19, 2013 7:02 PM, &quot;Nevin Liber&quot; &lt;<a href=3D"mailto:n=
evin@eviloverlord.com">nevin@eviloverlord.com</a>&gt; wrote:<br>
&gt;&gt; =A0 copy(from, to);<br>
&gt;&gt;<br>
&gt;&gt; =A0 context ctx;<br>
&gt;&gt; =A0 ctx.copy(from, to);<br>
&gt;<br>
&gt;<br>
&gt; So, you still want the error handling mechanism to be determined and c=
hangeable at run time? Um, okay (although I would vote strongly against suc=
h a thing), we can add &quot;do as iostreams does&quot; to the list.</p>

<p>My suggestion stops using runtime mechanisms long time ago.=A0 The curre=
nt version is, the free function one throws, the one with context does not.=
=A0 Imagine moving the error_code argument as the object, just they have di=
fferent types.</p>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bacbedcb6221f04e6c52b1e--

.

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

On Sep 19, 2013 7:01 PM, "Billy O'Neal" <billy.oneal@gmail.com> wrote:
> copy(from, to); //throws
>
> error_code ec = try_copy(from, to);

Unfortunately this does not work.  copy() is a special case which returns
nothing, while there are many others returning useful values.

--

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

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

<p>On Sep 19, 2013 7:01 PM, &quot;Billy O&#39;Neal&quot; &lt;<a href=3D"mai=
lto:billy.oneal@gmail.com">billy.oneal@gmail.com</a>&gt; wrote:<br>
&gt; copy(from, to); //throws<br>
&gt; =A0<br>
&gt; error_code ec =3D try_copy(from, to);</p>
<p>Unfortunately this does not work.=A0 copy() is a special case which retu=
rns nothing, while there are many others returning useful values.</p>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2c54a147d8904e6c533cd--

.

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

In that case, you have:

string s = parse_string(input);

string result;
error_code c = try_parse_string(input, result);

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Thu, Sep 19, 2013 at 4:49 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Sep 19, 2013 7:01 PM, "Billy O'Neal" <billy.oneal@gmail.com> wrote:
> > copy(from, to); //throws
> >
> > error_code ec = try_copy(from, to);
>
> Unfortunately this does not work.  copy() is a special case which returns
> nothing, while there are many others returning useful values.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr"><div>In that case, you have:</div><div>=A0</div><div>strin=
g s =3D parse_string(input);</div><div>=A0</div><div>string result;</div><d=
iv>error_code c =3D try_parse_string(input, result);</div></div><div class=
=3D"gmail_extra">

<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O&#39;Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Sep 19, 2013 at 4:49 PM, Zhihao =
Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blan=
k">zy@miator.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">

<p>On Sep 19, 2013 7:01 PM, &quot;Billy O&#39;Neal&quot; &lt;<a href=3D"mai=
lto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>&gt; =
wrote:<br>
&gt; copy(from, to); //throws<br>
&gt; =A0<br>
&gt; error_code ec =3D try_copy(from, to);</p>
<p>Unfortunately this does not work.=A0 copy() is a special case which retu=
rns nothing, while there are many others returning useful values.</p><div c=
lass=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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" 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 />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c2275e3b638c04e6c55a22--

.

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

On Sep 19, 2013 8:00 PM, "Billy O'Neal" <billy.oneal@gmail.com> wrote:
> In that case, you have:
>
> string s = parse_string(input);
>
> string result;
> error_code c = try_parse_string(input, result);

You successful brought me back to the assembly age.

--

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

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

<p>On Sep 19, 2013 8:00 PM, &quot;Billy O&#39;Neal&quot; &lt;<a href=3D"mai=
lto:billy.oneal@gmail.com">billy.oneal@gmail.com</a>&gt; wrote:<br>
&gt; In that case, you have:<br>
&gt; =A0<br>
&gt; string s =3D parse_string(input);<br>
&gt; =A0<br>
&gt; string result;<br>
&gt; error_code c =3D try_parse_string(input, result);</p>
<p>You successful brought me back to the assembly age.</p>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11c3ec700f97f504e6c57c6f--

.

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

Considering this is how it typically works in every language of which I am
aware, this is something from "the assembly age" that has legs.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Thu, Sep 19, 2013 at 5:09 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Sep 19, 2013 8:00 PM, "Billy O'Neal" <billy.oneal@gmail.com> wrote:
> > In that case, you have:
> >
> > string s = parse_string(input);
> >
> > string result;
> > error_code c = try_parse_string(input, result);
>
> You successful brought me back to the assembly age.
>
> --
>
> ---
> 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/.

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

<div dir=3D"ltr">Considering this is how it typically works in every langua=
ge of which I am aware, this is something from &quot;the assembly age&quot;=
 that has legs.</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div=
 dir=3D"ltr">

<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Thu, Sep 19, 2013 at 5:09 PM, Zhihao =
Yuan <span dir=3D"ltr">&lt;<a href=3D"mailto:zy@miator.net" target=3D"_blan=
k">zy@miator.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">

<div class=3D"im"><p>On Sep 19, 2013 8:00 PM, &quot;Billy O&#39;Neal&quot; =
&lt;<a href=3D"mailto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@=
gmail.com</a>&gt; wrote:<br>
&gt; In that case, you have:<br>
&gt; =A0<br>
&gt; string s =3D parse_string(input);<br>
&gt; =A0<br>
&gt; string result;<br>
&gt; error_code c =3D try_parse_string(input, result);</p>
</div><p>You successful brought me back to the assembly age.</p><div class=
=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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" 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 />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--089e0158b67014ccc004e6c58ea4--

.

On Thu, 2013-09-19 at 15:53 -0700, Billy O'Neal wrote:
> No, it would be different names:
>
> copy(from, to); //throws
>
> error_code ec = try_copy(from, to);
>
> Billy O'Neal
> https://github.com/BillyONeal/
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Thu, Sep 19, 2013 at 2:39 PM, Zhihao Yuan <zy@miator.net> wrote:
>         On Thu, Sep 19, 2013 at 5:28 PM, Nevin Liber
>         <nevin@eviloverlord.com> wrote:
>
>         > We just disagree with you on how to spell it.  I favor
>         different overloads;
>         > you favor templates, and still others favor different
>         function names.


There is one more version that no one have mentioned yet:

std::pair<res, ec> copy(from, to);

This is used for unique associative container insert(iter, value) so
there is a precedent in the standard.

For a simple bool return value this boils down to a std::optional return
value but the concept is easily extended to a proper return code as well
as multiple return values.


I have found this style to work well and not be to clunky, but I usually
do end up with some extraction helpers:


T check(std::pair<T, ec> val) {
  if (val.second.is_ok())
    return val.first;
  else
    throw val.second;
}

bool get(std::pair<T, ec> val, T& res) {
  if (val.second.is_ok()) {
    res = val.first;
    return true;
  }
  return false;
}


/MF

--

---
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 Thu, 19 Sep 2013 17:39:54 -0400, Zhihao Yuan <zy@miator.net> wrote:
> Overloads:
>
>   copy(from, to);
>
>   error_code ec;
>   copy(from, to, ec);
>
> My suggestion:
>
>   copy(from, to);
>
>   context ctx;
>   ctx.copy(from, to);

There is more than a syntax difference here.  Your proposition lacks
extensibility.  You have a difficult choice between:

- having a context which knows about all functions (so the user can't
add functions which share the context)

- you need a new context type per function, you have a lot of classes
whose behavior differ only by one member.

- you have a unlearnable mapping of contexts to functions.



I've used a design which always used error code and a "checked" class
template
which wrapped an error code and a value.  The error code and the
checked
template class throwed in their destructor if they weren't checked with
all the related issues I prefer to avoid in a standard.  We'll perhaps
have in the future a way to build something similar in a robust way,
but then from my POV the differences won't be important enough to
counterbalance the issues of having several styles in the SL.

Yours,

--
Jean-Marc

--

---
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 09/20/2013 08:53 AM, Magnus Fromreide wrote:

> There is one more version that no one have mentioned yet:
>
> std::pair<res, ec> copy(from, to);

And a vaguely related version is to use something like Alexandrescu's
Expected<>.

   std::expected<return_type> res = copy(from, to);
   std::expected<return_type, error_code> rest = copy(from, to);

The first may throw when res is accessed, the second will never throw.

There is a well-written Boost proposal of this class at:


http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/trademark/25002

--

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

.

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

On 20 September 2013 01:53, Magnus Fromreide <magfr@lysator.liu.se> wrote:

>
> std::pair<res, ec> copy(from, to);
>

-1.

pair and tuple are fine in generic constructs where it is impossible to
name things, but we are much better off with named things.

Whose eyes don't glaze over when they see constructs like
first->second.first?  Think about how much more readable code using maps
would have been had it stored elements in

struct value_type
{
    const key_type key;
    mapped_type value;
};

and insert returned


struct inserted
{
    iterator where;
    bool was_inserted;
};

I have found this style to work well and not be to clunky, but I usually
> do end up with some extraction helpers:
>
>
> T check(std::pair<T, ec> val) {
>   if (val.second.is_ok())
>     return val.first;
>   else
>     throw val.second;
> }
>
> bool get(std::pair<T, ec> val, T& res) {
>   if (val.second.is_ok()) {
>     res = val.first;
>     return true;
>   }
>   return false;
> }
>

If you had a need to have the extraction helpers, it's clunky to use.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

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

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

<div dir=3D"ltr">On 20 September 2013 01:53, Magnus Fromreide <span dir=3D"=
ltr">&lt;<a href=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@ly=
sator.liu.se</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
std::pair&lt;res, ec&gt; copy(from, to);<br></blockquote><div><br>-1.<br><b=
r></div><div>pair and tuple are fine in generic constructs where it is impo=
ssible to name things, but we are much better off with named things.<br>


<br></div><div>Whose eyes don&#39;t glaze over when they see constructs lik=
e first-&gt;second.first?=A0 Think about how much more readable code using =
maps would have been had it stored elements in<br><br>
struct value_type<br>{<br></div><div>=A0=A0=A0 const key_type key;<br></div=
><div>=A0=A0=A0 mapped_type value;<br></div><div>};<br><br></div><div>and i=
nsert returned<br><br></div><div><br></div><div>struct inserted<br>
{<br></div><div>=A0=A0=A0 iterator where;<br></div><div>=A0=A0=A0 bool was_=
inserted;<br></div><div>};<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have found this style to work well and not be to clunky, but I usually<br=
>
do end up with some extraction helpers:<br>
<br>
<br>
T check(std::pair&lt;T, ec&gt; val) {<br>
=A0 if (val.second.is_ok())<br>
=A0 =A0 return val.first;<br>
=A0 else<br>
=A0 =A0 throw val.second;<br>
}<br>
<br>
bool get(std::pair&lt;T, ec&gt; val, T&amp; res) {<br>
=A0 if (val.second.is_ok()) {<br>
=A0 =A0 res =3D val.first;<br>
=A0 =A0 return true;<br>
=A0 }<br>
=A0 return false;<br>
}<br></blockquote><div><br></div><div>If you had a need to have the extract=
ion helpers, it&#39;s clunky to use.<br></div></div>-- <br>=A0Nevin &quot;:=
-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" targ=
et=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20=
691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</a>
</div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a1133b3e416496304e6d542ef--

.

On Fri, 2013-09-20 at 13:57 -0500, Nevin Liber wrote:
> On 20 September 2013 01:53, Magnus Fromreide <magfr@lysator.liu.se>
> wrote:
>
>         std::pair<res, ec> copy(from, to);
> -1.
>
>
> pair and tuple are fine in generic constructs where it is impossible
> to name things, but we are much better off with named things.
>
>
> Whose eyes don't glaze over when they see constructs like
> first->second.first?  Think about how much more readable code using
> maps would have been had it stored elements in
>
> struct value_type
> {
>     const key_type key;
>     mapped_type value;
> };

> and insert returned

> struct inserted
> {
>     iterator where;
>     bool was_inserted;
> };

I agree with you, it would have been better.

Now, is it the use of pair<> as a return value or the return of an
object that contains either the result or the error code that you
objects to?

/MF

--

---
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_2284_16381330.1379770724988
Content-Type: text/plain; charset=ISO-8859-1

You can name return values:

iterator val;
bool ok;
std::tie(val, ok) = copy(from, to);
if (ok) do_something(to, val);


On Friday, September 20, 2013 8:57:57 PM UTC+2, Nevin ":-)" Liber wrote:
>
> On 20 September 2013 01:53, Magnus Fromreide <ma...@lysator.liu.se<javascript:>
> > wrote:
>
>>
>> std::pair<res, ec> copy(from, to);
>>
>
> -1.
>
> pair and tuple are fine in generic constructs where it is impossible to
> name things, but we are much better off with named things.
>
> Whose eyes don't glaze over when they see constructs like
> first->second.first?  Think about how much more readable code using maps
> would have been had it stored elements in
>
> struct value_type
> {
>     const key_type key;
>     mapped_type value;
> };
>
> and insert returned
>
>
> struct inserted
> {
>     iterator where;
>     bool was_inserted;
> };
>
> I have found this style to work well and not be to clunky, but I usually
>> do end up with some extraction helpers:
>>
>>
>> T check(std::pair<T, ec> val) {
>>   if (val.second.is_ok())
>>     return val.first;
>>   else
>>     throw val.second;
>> }
>>
>> bool get(std::pair<T, ec> val, T& res) {
>>   if (val.second.is_ok()) {
>>     res = val.first;
>>     return true;
>>   }
>>   return false;
>> }
>>
>
> If you had a need to have the extraction helpers, it's clunky to use.
> --
>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)
> 691-1404
>

--

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

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

<div dir=3D"ltr">You can name return values:<br><br><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">iterator val</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">bool</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> ok</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">tie</s=
pan><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-by-prettify"><code class=3D"prettyprint"><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">val</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: #000;" cl=
ass=3D"styled-by-prettify"></span></code>, </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">ok</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"></span></code>)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> copy</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">from</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> to</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">ok</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
do_something</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">to</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> val</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br><b=
r>On Friday, September 20, 2013 8:57:57 PM UTC+2, Nevin ":-)" Liber wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On 20 Septembe=
r 2013 01:53, Magnus Fromreide <span dir=3D"ltr">&lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"BsRafR6FuNIJ">ma...@lysator.li=
u.se</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote">



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
std::pair&lt;res, ec&gt; copy(from, to);<br></blockquote><div><br>-1.<br><b=
r></div><div>pair and tuple are fine in generic constructs where it is impo=
ssible to name things, but we are much better off with named things.<br>


<br></div><div>Whose eyes don't glaze over when they see constructs like fi=
rst-&gt;second.first?&nbsp; Think about how much more readable code using m=
aps would have been had it stored elements in<br><br>
struct value_type<br>{<br></div><div>&nbsp;&nbsp;&nbsp; const key_type key;=
<br></div><div>&nbsp;&nbsp;&nbsp; mapped_type value;<br></div><div>};<br><b=
r></div><div>and insert returned<br><br></div><div><br></div><div>struct in=
serted<br>
{<br></div><div>&nbsp;&nbsp;&nbsp; iterator where;<br></div><div>&nbsp;&nbs=
p;&nbsp; bool was_inserted;<br></div><div>};<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
I have found this style to work well and not be to clunky, but I usually<br=
>
do end up with some extraction helpers:<br>
<br>
<br>
T check(std::pair&lt;T, ec&gt; val) {<br>
&nbsp; if (val.second.is_ok())<br>
&nbsp; &nbsp; return val.first;<br>
&nbsp; else<br>
&nbsp; &nbsp; throw val.second;<br>
}<br>
<br>
bool get(std::pair&lt;T, ec&gt; val, T&amp; res) {<br>
&nbsp; if (val.second.is_ok()) {<br>
&nbsp; &nbsp; res =3D val.first;<br>
&nbsp; &nbsp; return true;<br>
&nbsp; }<br>
&nbsp; return false;<br>
}<br></blockquote><div><br></div><div>If you had a need to have the extract=
ion helpers, it's clunky to use.<br></div></div>-- <br>&nbsp;Nevin ":-)" Li=
ber&nbsp; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"BsRafR6FuNIJ">ne...@eviloverlord.com</a><wbr>&gt;&nbsp; <a val=
ue=3D"+18476911404">(847) 691-1404</a>
</div></div>
</blockquote></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2284_16381330.1379770724988--

.

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

True, and if the object returned is cheap to copy/move then that's fine.
But if it isn't (e.g. returning a std::array), this is problematic because
the potentially expensive return value is not eligible for RVO / NRVO.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Sat, Sep 21, 2013 at 6:38 AM, <inkwizytoryankes@gmail.com> wrote:

> You can name return values:
>
> iterator val;
> bool ok;
> std::tie(val, ok) = copy(from, to);
> if (ok) do_something(to, val);
>
>
> On Friday, September 20, 2013 8:57:57 PM UTC+2, Nevin ":-)" Liber wrote:
>>
>> On 20 September 2013 01:53, Magnus Fromreide <ma...@lysator.liu.se>wrote:
>>
>>>
>>> std::pair<res, ec> copy(from, to);
>>>
>>
>> -1.
>>
>> pair and tuple are fine in generic constructs where it is impossible to
>> name things, but we are much better off with named things.
>>
>> Whose eyes don't glaze over when they see constructs like
>> first->second.first?  Think about how much more readable code using maps
>> would have been had it stored elements in
>>
>> struct value_type
>> {
>>     const key_type key;
>>     mapped_type value;
>> };
>>
>> and insert returned
>>
>>
>> struct inserted
>> {
>>     iterator where;
>>     bool was_inserted;
>> };
>>
>> I have found this style to work well and not be to clunky, but I usually
>>> do end up with some extraction helpers:
>>>
>>>
>>> T check(std::pair<T, ec> val) {
>>>   if (val.second.is_ok())
>>>     return val.first;
>>>   else
>>>     throw val.second;
>>> }
>>>
>>> bool get(std::pair<T, ec> val, T& res) {
>>>   if (val.second.is_ok()) {
>>>     res = val.first;
>>>     return true;
>>>   }
>>>   return false;
>>> }
>>>
>>
>> If you had a need to have the extraction helpers, it's clunky to use.
>> --
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com**>  (847) 691-1404
>>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr">True, and if the object returned is cheap to copy/move the=
n that&#39;s fine. But if it isn&#39;t (e.g. returning a std::array), this =
is problematic because the potentially expensive return value is not eligib=
le for RVO / NRVO.</div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Sat, Sep 21, 2013 at 6:38 AM,  <span =
dir=3D"ltr">&lt;<a href=3D"mailto:inkwizytoryankes@gmail.com" target=3D"_bl=
ank">inkwizytoryankes@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">You can name return values:<br><br><div style=3D"border:1p=
x solid rgb(187,187,187);background-color:rgb(250,250,250)"><code><div><spa=
n>iterator val</span><span style=3D"color:rgb(102,102,0)">;</span><span><br=
>
</span><span style=3D"color:rgb(0,0,136)">bool</span><span> ok</span><span =
style=3D"color:rgb(102,102,0)">;</span><span><br>
std</span><span style=3D"color:rgb(102,102,0)">::</span><span>tie</span><sp=
an style=3D"color:rgb(102,102,0)">(</span><span></span><span style=3D"color=
:rgb(102,102,0)"><code><span style=3D"color:rgb(0,0,0)">val</span><span sty=
le=3D"color:rgb(102,102,0)"></span><span style=3D"color:rgb(0,0,0)"></span>=
<span style=3D"color:rgb(0,0,0)"></span></code>, </span><span style=3D"colo=
r:rgb(102,102,0)"><code><span style=3D"color:rgb(0,0,0)">ok</span><span sty=
le=3D"color:rgb(102,102,0)"></span><span style=3D"color:rgb(0,0,0)"></span>=
</code>)</span><span> </span><span style=3D"color:rgb(102,102,0)">=3D</span=
><span> copy</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,136)">from</span><span style=3D"color:rgb(102,102,0)">,</=
span><span> to</span><span style=3D"color:rgb(102,102,0)">);</span><span><b=
r>

</span><span style=3D"color:rgb(0,0,136)">if</span><span> </span><span styl=
e=3D"color:rgb(102,102,0)">(</span><span>ok</span><span style=3D"color:rgb(=
102,102,0)">)</span><span> do_something</span><span style=3D"color:rgb(102,=
102,0)">(</span><span>to</span><span style=3D"color:rgb(102,102,0)">,</span=
><span> val</span><span style=3D"color:rgb(102,102,0)">);</span><span><br>

</span></div></code></div><br><br>On Friday, September 20, 2013 8:57:57 PM =
UTC+2, Nevin &quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid">

<div dir=3D"ltr">On 20 September 2013 01:53, Magnus Fromreide <span dir=3D"=
ltr">&lt;<a>ma...@lysator.liu.se</a>&gt;</span> wrote:<br><div><div class=
=3D"gmail_quote">



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><br>
std::pair&lt;res, ec&gt; copy(from, to);<br></blockquote><div><br>-1.<br><b=
r></div><div>pair and tuple are fine in generic constructs where it is impo=
ssible to name things, but we are much better off with named things.<br>




<br></div><div>Whose eyes don&#39;t glaze over when they see constructs lik=
e first-&gt;second.first?=A0 Think about how much more readable code using =
maps would have been had it stored elements in<br><br>
struct value_type<br>{<br></div><div>=A0=A0=A0 const key_type key;<br></div=
><div>=A0=A0=A0 mapped_type value;<br></div><div>};<br><br></div><div>and i=
nsert returned<br><br></div><div><br></div><div>struct inserted<br>
{<br></div><div>=A0=A0=A0 iterator where;<br></div><div>=A0=A0=A0 bool was_=
inserted;<br></div><div>};<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204=
,204,204);border-left-width:1px;border-left-style:solid">


I have found this style to work well and not be to clunky, but I usually<br=
>
do end up with some extraction helpers:<br>
<br>
<br>
T check(std::pair&lt;T, ec&gt; val) {<br>
=A0 if (val.second.is_ok())<br>
=A0 =A0 return val.first;<br>
=A0 else<br>
=A0 =A0 throw val.second;<br>
}<br>
<br>
bool get(std::pair&lt;T, ec&gt; val, T&amp; res) {<br>
=A0 if (val.second.is_ok()) {<br>
=A0 =A0 res =3D val.first;<br>
=A0 =A0 return true;<br>
=A0 }<br>
=A0 return false;<br>
}<br></blockquote><div><br></div><div>If you had a need to have the extract=
ion helpers, it&#39;s clunky to use.<span class=3D"HOEnZb"><font color=3D"#=
888888"><br></font></span></div></div><span class=3D"HOEnZb"><font color=3D=
"#888888">-- <br>

=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a>ne...@eviloverlord.com</a><=
u></u>&gt;=A0 <a value=3D"+18476911404">(847) 691-1404</a>
</font></span></div></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888=
888">

<p></p>

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

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--001a11334600dc25fc04e6ea1aa2--

.

------=_Part_399_7589368.1379794047098
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

For the from_string case in particular it is not so easy to know inside the=
=20
function what is an error and not. If the input string comes from a user=20
input it is reasonable to flag an error if the entire string can't be=20
interpreted as a T. For a field in a larger value this is useless as you=20
can't parse the value without getting an exception. In addition you need to=
=20
know how many characters were consumed in this case, which requires a=20
return value or a reference size_t variable. This has been observed for the=
=20
stoi group of functions introduced in C++11. These throw if no characters=
=20
could be consumed and otherwise they set the (optional) pos value to the=20
number of converted characters. The remaining problem with this approach is=
=20
that it accepts any junk text after one allowable characters unless you=20
check the pos value afterwards.

Personally I would have liked to have overloaded from_string() functions=20
instead of all of those different sto* functions so that they could have=20
been used in template code. Such a signature would have had to have the=20
destination as a reference parameter which would have allowed the consumed=
=20
character count to be a return value. This concept would then easily carry=
=20
over to for instance ip::address_v4 as another overloaded free function.

Given that sto* was selected for basic types it would be logical to add a=
=20
stoaddress_v4 to the ip namespace or class. It does not seem logical to=20
change to another paradigm now. It would be possible to add from_string()=
=20
functions in parallel to the C+11 sto* functions but I imagine this would=
=20
be hard to get through the committe now that the sto* approach has been=20
selected.

A further comment is that if the optional pos pointer of the sto* functions=
=20
is nullptr it would have been possible to define that they should throw if=
=20
the entire string could not be converted, but this does not seem to be the=
=20
case.

Den l=F6rdagen den 21:e september 2013 kl. 15:38:44 UTC+2 skrev=20
inkwizyt...@gmail.com:
>
> You can name return values:
>
> iterator val;
> bool ok;
> std::tie(val, ok) =3D copy(from, to);
> if (ok) do_something(to, val);
>
>
> On Friday, September 20, 2013 8:57:57 PM UTC+2, Nevin ":-)" Liber wrote:
>>
>> On 20 September 2013 01:53, Magnus Fromreide <ma...@lysator.liu.se>wrote=
:
>>
>>>
>>> std::pair<res, ec> copy(from, to);
>>>
>>
>> -1.
>>
>> pair and tuple are fine in generic constructs where it is impossible to=
=20
>> name things, but we are much better off with named things.
>>
>> Whose eyes don't glaze over when they see constructs like=20
>> first->second.first?  Think about how much more readable code using maps=
=20
>> would have been had it stored elements in
>>
>> struct value_type
>> {
>>     const key_type key;
>>     mapped_type value;
>> };
>>
>> and insert returned
>>
>>
>> struct inserted
>> {
>>     iterator where;
>>     bool was_inserted;
>> };
>>
>> I have found this style to work well and not be to clunky, but I usually
>>> do end up with some extraction helpers:
>>>
>>>
>>> T check(std::pair<T, ec> val) {
>>>   if (val.second.is_ok())
>>>     return val.first;
>>>   else
>>>     throw val.second;
>>> }
>>>
>>> bool get(std::pair<T, ec> val, T& res) {
>>>   if (val.second.is_ok()) {
>>>     res =3D val.first;
>>>     return true;
>>>   }
>>>   return false;
>>> }
>>>
>>
>> If you had a need to have the extraction helpers, it's clunky to use.
>> --=20
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404=20
>>
>

--=20

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

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

<div dir=3D"ltr">For the from_string case in particular it is not so easy t=
o know inside the function what is an error and not. If the input string co=
mes from a user input it is reasonable to flag an error if the entire strin=
g can't be interpreted as a T. For a field in a larger value this is useles=
s as you can't parse the value without getting an exception. In addition yo=
u need to know how many characters were consumed in this case, which requir=
es a return value or a reference size_t variable. This has been observed fo=
r the stoi group of functions introduced in C++11. These throw if no charac=
ters could be consumed and otherwise they set the (optional) pos value to t=
he number of converted characters. The remaining problem with this approach=
 is that it accepts any junk text after one allowable characters unless you=
 check the pos value afterwards.<div><br></div><div>Personally I would have=
 liked to have overloaded from_string() functions instead of all of those d=
ifferent sto* functions so that they could have been used in template code.=
 Such a signature would have had to have the destination as a reference par=
ameter which would have allowed the consumed character count to be a return=
 value. This concept would then easily carry over to for instance ip::addre=
ss_v4 as another overloaded free function.</div><div><br></div><div>Given t=
hat sto* was selected for basic types it would be logical to add a stoaddre=
ss_v4 to the ip namespace or class. It does not seem logical to change to a=
nother paradigm now. It would be possible to add from_string() functions in=
 parallel to the C+11 sto* functions but I imagine this would be hard to ge=
t through the committe now that the sto* approach has been selected.</div><=
div><br></div><div>A further comment is that if the optional pos pointer of=
 the sto* functions is nullptr it would have been possible to define that t=
hey should throw if the entire string could not be converted, but this does=
 not seem to be the case.<br><br>Den l=F6rdagen den 21:e september 2013 kl.=
 15:38:44 UTC+2 skrev inkwizyt...@gmail.com:<blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">You can name return values:<br><br><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#000">iterator val</span><span style=3D"color:#660">;</span><span=
 style=3D"color:#000"><br></span><span style=3D"color:#008">bool</span><spa=
n style=3D"color:#000"> ok</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"><br>std</span><span style=3D"color:#660">::</span><span=
 style=3D"color:#000">tie</span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000"></span><span style=3D"color:#660"><code><span style=3D"c=
olor:#000">val</span><span style=3D"color:#660"></span><span style=3D"color=
:#000"></span><span style=3D"color:#000"></span></code>, </span><span style=
=3D"color:#660"><code><span style=3D"color:#000">ok</span><span style=3D"co=
lor:#660"></span><span style=3D"color:#000"></span></code>)</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> copy</span><span style=3D"color:#660">(</span><span style=
=3D"color:#008">from</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> to</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#008">if</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">ok</span><span style=3D"color:#660">)</span><span style=3D"color=
:#000"> do_something</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">to</span><span style=3D"color:#660">,</span><span style=3D"=
color:#000"> val</span><span style=3D"color:#660">);</span><span style=3D"c=
olor:#000"><br></span></div></code></div><br><br>On Friday, September 20, 2=
013 8:57:57 PM UTC+2, Nevin ":-)" Liber wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">On 20 September 2013 01:53, Magnus Fromreide <s=
pan dir=3D"ltr">&lt;<a>ma...@lysator.liu.se</a>&gt;</span> wrote:<br><div><=
div class=3D"gmail_quote">



<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
std::pair&lt;res, ec&gt; copy(from, to);<br></blockquote><div><br>-1.<br><b=
r></div><div>pair and tuple are fine in generic constructs where it is impo=
ssible to name things, but we are much better off with named things.<br>


<br></div><div>Whose eyes don't glaze over when they see constructs like fi=
rst-&gt;second.first?&nbsp; Think about how much more readable code using m=
aps would have been had it stored elements in<br><br>
struct value_type<br>{<br></div><div>&nbsp;&nbsp;&nbsp; const key_type key;=
<br></div><div>&nbsp;&nbsp;&nbsp; mapped_type value;<br></div><div>};<br><b=
r></div><div>and insert returned<br><br></div><div><br></div><div>struct in=
serted<br>
{<br></div><div>&nbsp;&nbsp;&nbsp; iterator where;<br></div><div>&nbsp;&nbs=
p;&nbsp; bool was_inserted;<br></div><div>};<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
I have found this style to work well and not be to clunky, but I usually<br=
>
do end up with some extraction helpers:<br>
<br>
<br>
T check(std::pair&lt;T, ec&gt; val) {<br>
&nbsp; if (val.second.is_ok())<br>
&nbsp; &nbsp; return val.first;<br>
&nbsp; else<br>
&nbsp; &nbsp; throw val.second;<br>
}<br>
<br>
bool get(std::pair&lt;T, ec&gt; val, T&amp; res) {<br>
&nbsp; if (val.second.is_ok()) {<br>
&nbsp; &nbsp; res =3D val.first;<br>
&nbsp; &nbsp; return true;<br>
&nbsp; }<br>
&nbsp; return false;<br>
}<br></blockquote><div><br></div><div>If you had a need to have the extract=
ion helpers, it's clunky to use.<br></div></div>-- <br>&nbsp;Nevin ":-)" Li=
ber&nbsp; &lt;mailto:<a>ne...@eviloverlord.com</a><wbr>&gt;&nbsp; <a value=
=3D"+18476911404">(847) 691-1404</a>
</div></div>
</blockquote></div></blockquote></div></div>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_399_7589368.1379794047098--

.