The filesystem TS reports error via exceptions or error_code depending
on which overload is used.

In some cases the error_code overloads return an additional error
indication. For instance:

   uintmax_t file_size(const path& p, error_code&) noexcept;

will return static_cast<uintmax_t>(-1) if an error occurred, and the
actual error is reported in the error_code out parameter.

A better approach would be to use the expected<T,E> proposal (N4015)
to return error codes for the noexcept overloads:

   expected<uintmax_t, error_code> file_size(const path& p) noexcept;

This way we do not have to rely on magic numbers, and the usability of
the filesystem TS is improved. With the current proposal the user has
to write this code:

   error_code error;
   auto size = file_size(p, error);
   if (size == static_cast<uintmax_t>(-1))
     return error;

With an expected return value it becomes:

   auto size = file_size(p);
   if (!size)
     return size.error();

I know that the filesystem TS is ahead of the expected<> proposal, but
it may be sensible to consider expected<> before the filesystem TS is
moved out of the experimental namespace.

--

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

.

Hi,

On 12/10/2014 13:30, Bjorn Reese wrote:
> (...)
> With an expected return value it becomes:
>
>   auto size = file_size(p);
>   if (!size)
>     return size.error();

It won't be possible to disambiguate from the other overload then, or am
I missing something ?

MAT.

--

---
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 10/12/2014 01:50 PM, Mathieu Champlon wrote:
> Hi,
>
> On 12/10/2014 13:30, Bjorn Reese wrote:
>> (...)
>> With an expected return value it becomes:
>>
>>   auto size = file_size(p);
>>   if (!size)
>>     return size.error();
>
> It won't be possible to disambiguate from the other overload then, or am
> I missing something ?

You are right. We need something to disambiguate it. One possibility
could be a tag, akin to the use_future in N4045.

However, before going into deatils, I wanted to gauge the interest in
using expected<> in filesystem rather than special values to indicate
errors.

--

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

There have been concerns about such error handling before. AFAIK they
weren't addressed.

Personally I'd prefer the error code to be returned, allowing for code like
   uintmax_t size;
   if (auto error = file_size(p, size))
    return error;
  //use size instead of size.get() or something like it.

--

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

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

<div dir=3D"ltr">There have been concerns about such error handling before.=
 AFAIK they weren't addressed.<div><br></div><div>Personally I'd prefer the=
 error code to be returned, allowing for code like</div><div>&nbsp; &nbsp;u=
intmax_t size;</div><div>&nbsp; &nbsp;if (auto error =3D&nbsp;file_size(p, =
size))</div><div>&nbsp; &nbsp; return error;</div><div>&nbsp; //use size in=
stead of size.get() or something like it.</div></div>

<p></p>

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

------=_Part_230_1015930689.1413214504825--

.

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

Error code reporting could be used in platforms where exception handling is
too heavy (i.e. some embedded systems).
El 13/10/2014 12:35, "Olaf van der Spek" <olafvdspek@gmail.com> escribi=C3=
=B3:

> There have been concerns about such error handling before. AFAIK they
> weren't addressed.
>
> Personally I'd prefer the error code to be returned, allowing for code li=
ke
>    uintmax_t size;
>    if (auto error =3D file_size(p, size))
>     return error;
>   //use size instead of size.get() or something like it.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

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

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

<p>Error code reporting could be used in platforms where exception handling=
 is too heavy (i.e. some embedded systems).</p>
<div class=3D"gmail_quote">El 13/10/2014 12:35, &quot;Olaf van der Spek&quo=
t; &lt;<a href=3D"mailto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt;=
 escribi=C3=B3:<br type=3D"attribution"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">There have been concerns about such error handling before. AFA=
IK they weren&#39;t addressed.<div><br></div><div>Personally I&#39;d prefer=
 the error code to be returned, allowing for code like</div><div>=C2=A0 =C2=
=A0uintmax_t size;</div><div>=C2=A0 =C2=A0if (auto error =3D=C2=A0file_size=
(p, size))</div><div>=C2=A0 =C2=A0 return error;</div><div>=C2=A0 //use siz=
e instead of size.get() or something like it.</div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" 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>
</blockquote></div>

<p></p>

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

--001a11c163286f9b560505502a3d--

.

On 2014-10-13 08:02, Bjorn Reese wrote:
> On 10/12/2014 01:50 PM, Mathieu Champlon wrote:
>> Hi,
>>
>> On 12/10/2014 13:30, Bjorn Reese wrote:
>>> (...)
>>> With an expected return value it becomes:
>>>
>>>   auto size = file_size(p);
>>>   if (!size)
>>>     return size.error();
>>
>> It won't be possible to disambiguate from the other overload then, or am
>> I missing something ?
>
> You are right. We need something to disambiguate it. One possibility
> could be a tag, akin to the use_future in N4045.

1. Yes, please use std::expected.

2. Doesn't std::expected throw if you try to dereference it and it is
"disengaged" (or whatever is the terminology)? What I'm thinking is, do
we even *need* throwing flavors, or can we just use std::expected and
fold the two together?

IIRC the entire point of std::expected was to get rid of this nonsense
and just *always* return "a result" in the form of std::expected, which
would contain either a useful return value or an error condition.

--
Matthew

--

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

.

On 13 October 2014 20:07, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> 1. Yes, please use std::expected.

You people seriously need to hold your horses. expected is nowhere near being
std::expected, so filesystem cannot use it yet. IF expected gets accepted, then
the API of filesystem can consider using it, but not before.

--

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



On Tuesday, October 14, 2014 4:35:04 AM UTC+13, Olaf van der Spek wrote:
>
> There have been concerns about such error handling before. AFAIK they
> weren't addressed.
>
> Personally I'd prefer the error code to be returned, allowing for code like
>    uintmax_t size;
>    if (auto error = file_size(p, size))
>     return error;
>   //use size instead of size.get() or something like it.
>

I am thinking so too. There may be an argument against this, but if so, I'd
like to hear it.

--

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

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

<div dir=3D"ltr"><br><br>On Tuesday, October 14, 2014 4:35:04 AM UTC+13, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">There h=
ave been concerns about such error handling before. AFAIK they weren't addr=
essed.<div><br></div><div>Personally I'd prefer the error code to be return=
ed, allowing for code like</div><div>&nbsp; &nbsp;uintmax_t size;</div><div=
>&nbsp; &nbsp;if (auto error =3D&nbsp;file_size(p, size))</div><div>&nbsp; =
&nbsp; return error;</div><div>&nbsp; //use size instead of size.get() or s=
omething like it.</div></div></blockquote><div><br></div><div>I&nbsp;am thi=
nking so too.&nbsp;There may be&nbsp;an argument against this, but if so, I=
'd like to hear it.&nbsp;</div></div>

<p></p>

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

------=_Part_3536_355384747.1413242108011--

.

------=_Part_3566_18386310.1413244907743
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 14, 2014 4:35:04 AM UTC+13, Olaf van der Spek wrote:
>
> There have been concerns about such error handling before. AFAIK they
> weren't addressed.
>
>
> I raised some concerns about the issue in a post a while back with
the subject "Thoughts on the filesystem proposal".
It didn't generate much discussion though. Someone did suggest it was
better to post on the boost website instead.

I just chose not to for lots of reasons. But I'd be astounded if
Beman wasn't checking this forum now and again anyway. I've also
assumed that if there was anything of merit in my comments in that
post, there is enough heavy weights on this forum that they would
have picked it apart to start a ball rolling to get any attention if it
were needed.

So I'm just waiting to see how the filesystem proposal goes. I haven't been
confident the API will actually be easier to use than many of the C API's
it will replace, especially for directory and sub directory iteration with
error handling,  But until you hard out convert a load of code from old to
new it's hard to know. I know a lot of work is going into this which I
appreciate so I'm hoping things will turn out well.

--

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

<div dir=3D"ltr"><br><br>On Tuesday, October 14, 2014 4:35:04 AM UTC+13, Ol=
af van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">There h=
ave been concerns about such error handling before. AFAIK they weren't addr=
essed.<div><br></div><div><br></div></div></blockquote><div>I&nbsp;raised s=
ome concerns&nbsp;about the issue in a post a while back with the&nbsp;subj=
ect&nbsp;"Thoughts on the filesystem proposal".</div><div>It didn't generat=
e&nbsp;much discussion though. Someone&nbsp;did suggest it was better to po=
st on the boost website instead.</div><div><br></div><div>I just&nbsp;chose=
 not to for lots of reasons. But I'd be astounded if Beman&nbsp;wasn't chec=
king this forum now and again anyway. I've also assumed&nbsp;that if there&=
nbsp;was anything of merit in my comments in&nbsp;that post,&nbsp;there is =
enough heavy weights&nbsp;on this forum&nbsp;that they would have&nbsp;pick=
ed it apart to start&nbsp;a ball rolling to get any attention if it were ne=
eded.</div><div><br></div><div>So I'm just waiting to see how&nbsp;the file=
system proposal&nbsp;goes. I&nbsp;haven't&nbsp;been confident the API&nbsp;=
will&nbsp;actually be easier to use than many of the C API's it will replac=
e,&nbsp;especially for directory and sub directory iteration&nbsp;with erro=
r handling,&nbsp; But until you&nbsp;hard out convert a load of code from o=
ld to new it's hard to know. I know a lot of work is going into this which =
I appreciate so I'm hoping things will turn out well.</div></div>

<p></p>

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

------=_Part_3566_18386310.1413244907743--

.

Il giorno 13/ott/2014, alle ore 19:37, Ville Voutilainen <ville.voutilainen=
@gmail.com> ha scritto:
>=20
> On 13 October 2014 20:07, Matthew Woehlke
> <mw_triad@users.sourceforge.net> wrote:
>> 1. Yes, please use std::expected.
>=20
> You people seriously need to hold your horses. expected is nowhere near b=
eing
> std::expected, so filesystem cannot use it yet. IF expected gets accepted=
, then
> the API of filesystem can consider using it, but not before.
>=20

You're right! We extremely need expected to be accepted. Do you expect (!!)=
 it do be? Anyway, if not std::expected, what about std::optional? We alrea=
dy have it in the library fundamentals. With optional you could have a solu=
tion that's better than the current one with return codes, but slightly wor=
se than with the hypothetical expected, e.g. two overloads, the first throw=
ing on error, the second returning an optional and setting the error code t=
o an out parameter.

In any case I think returning things like static_cast<whatever>(-1) is not =
only very ugly for a modern C++ library, especially a library proposed for =
standardization, but it goes straight against everything we're teaching out=
 there. So it's worth discussing, I think.

Best regards,
Nicola=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/.

.

On 14 October 2014 11:46, Nicola Gigante <nicola.gigante@gmail.com> wrote:
>> You people seriously need to hold your horses. expected is nowhere near =
being
>> std::expected, so filesystem cannot use it yet. IF expected gets accepte=
d, then
>> the API of filesystem can consider using it, but not before.
> You're right! We extremely need expected to be accepted. Do you expect (!=
!) it do be? Anyway, if not

I don't want to make predictions. It has a good rationale, but there
are disagreeing opinions
on standardizing such facilities that provide an error handling
alternative to exceptions.
I know, I know, there are many domains in which you don't want
exceptions (collecting the results
of multiple parallel tasks, for example..), but it's likely there's
going to be some sort of a
guidance/direction discussion exploding out of this rather simple
library facility proposal.

>std::expected, what about std::optional? We already have it in the library=
 fundamentals. With optional you could have a solution that's better than t=
he current one with return codes, but slightly worse than with the hypothet=
ical expected, e.g. two overloads, the first throwing on error, the second =
returning an optional and setting the error code to an out parameter.

The Library Fundamentals TS is still under ballot (as is Filesystem),
so it's a tad icky to make
one TS depend on another that way.

> In any case I think returning things like static_cast<whatever>(-1) is no=
t only very ugly for a modern C++ library, especially a library proposed fo=
r standardization, but it goes straight against everything we're teaching o=
ut there. So it's worth discussing, I think.

Certainly. And it's likely worth revisiting before the Filesystem TS
gets incorporated into
an actual standard, but all in due course.

--=20

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

.

On 10/13/2014 07:07 PM, Matthew Woehlke wrote:

> 2. Doesn't std::expected throw if you try to dereference it and it is
> "disengaged" (or whatever is the terminology)? What I'm thinking is, do
> we even *need* throwing flavors, or can we just use std::expected and
> fold the two together?

It should be possible to fold them together. You get an exception if
you call value() on an expected object that contains an unexpected
value, so this will throw on error:

   auto size = file_size(p).value();

Unfortunately you get a bad_expected_access<E> exception rather than
a system_error or filesystem_error. It is still unresolved how you get
another type of exception, but there are several discussions about it
in the expected proposal (e.g. section 7.2, 7.4, 7.5, and 7.8 in N4015.)

--

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

.

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

On Tue, Oct 14, 2014 at 6:44 AM, Bjorn Reese <breese@mail1.stofanet.dk>
wrote:

> On 10/13/2014 07:07 PM, Matthew Woehlke wrote:
>
>  2. Doesn't std::expected throw if you try to dereference it and it is
>> "disengaged" (or whatever is the terminology)? What I'm thinking is, do
>> we even *need* throwing flavors, or can we just use std::expected and
>> fold the two together?
>>
>
> It should be possible to fold them together. You get an exception if
> you call value() on an expected object that contains an unexpected
> value, so this will throw on error:
>
>   auto size = file_size(p).value();
>
> Unfortunately you get a bad_expected_access<E> exception rather than
> a system_error or filesystem_error. It is still unresolved how you get
> another type of exception, but there are several discussions about it
> in the expected proposal (e.g. section 7.2, 7.4, 7.5, and 7.8 in N4015.)
>
>
IIRC, expected<T,E> will throw E (instead of bad_expected_access) if E is
derived from std::exception.  (Or maybe that changed from the first version
of expected<>?)

Tony

--

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

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Oct 14, 2014 at 6:44 AM, Bjorn Reese <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:breese@mail1.stofanet.dk" target=3D"_blank">breese@mail1.stof=
anet.dk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">On 10/13/2014 07:07 PM, Matthew Woehlke wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
2. Doesn&#39;t std::expected throw if you try to dereference it and it is<b=
r>
&quot;disengaged&quot; (or whatever is the terminology)? What I&#39;m think=
ing is, do<br>
we even *need* throwing flavors, or can we just use std::expected and<br>
fold the two together?<br>
</blockquote>
<br></span>
It should be possible to fold them together. You get an exception if<br>
you call value() on an expected object that contains an unexpected<br>
value, so this will throw on error:<br>
<br>
=C2=A0 auto size =3D file_size(p).value();<br>
<br>
Unfortunately you get a bad_expected_access&lt;E&gt; exception rather than<=
br>
a system_error or filesystem_error. It is still unresolved how you get<br>
another type of exception, but there are several discussions about it<br>
in the expected proposal (e.g. section 7.2, 7.4, 7.5, and 7.8 in N4015.)<di=
v class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote></div><br=
></div><div class=3D"gmail_extra">IIRC, expected&lt;T,E&gt; will throw E (i=
nstead of bad_expected_access) if E is derived from std::exception.=C2=A0 (=
Or maybe that changed from the first version of expected&lt;&gt;?)<br><br><=
/div><div class=3D"gmail_extra">Tony<br><br></div></div>

<p></p>

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

--001a1133afa0d14f520505630202--

.

Considering the overloads, we already have nothrow_t and nothrow, so=20
hypothetically one could use this tag to distinguish the signatures as=20
is done with new.

auto size =3D file_size(p); // throw on error
auto size =3D file_size(p, nothrow); // Returns optional/expected/whathavey=
ou

Am 14.10.2014 um 10:46 schrieb Nicola Gigante:
> Il giorno 13/ott/2014, alle ore 19:37, Ville Voutilainen <ville.voutilain=
en@gmail.com> ha scritto:
>> On 13 October 2014 20:07, Matthew Woehlke
>> <mw_triad@users.sourceforge.net> wrote:
>>> 1. Yes, please use std::expected.
>> You people seriously need to hold your horses. expected is nowhere near =
being
>> std::expected, so filesystem cannot use it yet. IF expected gets accepte=
d, then
>> the API of filesystem can consider using it, but not before.
>>
> You're right! We extremely need expected to be accepted. Do you expect (!=
!) it do be? Anyway, if not std::expected, what about std::optional? We alr=
eady have it in the library fundamentals. With optional you could have a so=
lution that's better than the current one with return codes, but slightly w=
orse than with the hypothetical expected, e.g. two overloads, the first thr=
owing on error, the second returning an optional and setting the error code=
 to an out parameter.
>
> In any case I think returning things like static_cast<whatever>(-1) is no=
t only very ugly for a modern C++ library, especially a library proposed fo=
r standardization, but it goes straight against everything we're teaching o=
ut there. So it's worth discussing, I think.
>
> Best regards,
> Nicola
>

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

.

This is a multi-part message in MIME format.
--------------070202050005090308060103
Content-Type: text/plain; charset=UTF-8; format=flowed


On 14/10/2014 16:41, Tony V E wrote:
>
>
> On Tue, Oct 14, 2014 at 6:44 AM, Bjorn Reese <breese@mail1.stofanet.dk
> <mailto:breese@mail1.stofanet.dk>> wrote:
>
>     On 10/13/2014 07:07 PM, Matthew Woehlke wrote:
>
>         2. Doesn't std::expected throw if you try to dereference it
>         and it is
>         "disengaged" (or whatever is the terminology)? What I'm
>         thinking is, do
>         we even *need* throwing flavors, or can we just use
>         std::expected and
>         fold the two together?
>
>
>     It should be possible to fold them together. You get an exception if
>     you call value() on an expected object that contains an unexpected
>     value, so this will throw on error:
>
>       auto size = file_size(p).value();
>
>     Unfortunately you get a bad_expected_access<E> exception rather than
>     a system_error or filesystem_error. It is still unresolved how you get
>     another type of exception, but there are several discussions about it
>     in the expected proposal (e.g. section 7.2, 7.4, 7.5, and 7.8 in
>     N4015.)
>
>
> IIRC, expected<T,E> will throw E (instead of bad_expected_access) if E
> is derived from std::exception.  (Or maybe that changed from the first
> version of expected<>?)
It's still under discussion, we first thought of an
expected_traits<E>::bad_access function called in this particular case.
The trait is specialized (by default) for std::exception_ptr, and
error_condition/code. Which is proposed in the section 8.2 of N4109. The
implementation is a step further and try to implement a more general
solution in term of monads.

There is endless discussion about expected and, IMHO, it shows that it's
hard to incorporate functional features into C++, such as monad in this
case. The problem being that doing that in a backward compatible way is
extremely difficult. Anyways, with expected we show that it is possible
to merge the two worlds. If you return an expected, the user is able to
choose if he wants to use exception (by calling value()) or to use the
functional paradigm (with then/map/...). Note that it is possible to
make expected exception-free if you customize the trait in this way.

The major argument against expected is that some people think that we
should stick to exception to handle errors, so no more than one
"official" way would be provided. With languages becoming more and more
multi-paradigm, I don't think that being too conservative is the way to go.

Pierre
>
> Tony
>
> --
>
> ---
> 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
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto: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/.

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

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <br>
    <div class=3D"moz-cite-prefix">On 14/10/2014 16:41, Tony V E wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CAOHCbisTaT83VmW8jZCwvejU_n4UGtK=3D-rjgXzwsHNy3H=3DTVNQ@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <div class=3D"gmail_extra"><br>
          <div class=3D"gmail_quote">On Tue, Oct 14, 2014 at 6:44 AM,
            Bjorn Reese <span dir=3D"ltr">&lt;<a moz-do-not-send=3D"true"
                href=3D"mailto:breese@mail1.stofanet.dk" target=3D"_blank">=
breese@mail1.stofanet.dk</a>&gt;</span>
            wrote:<br>
            <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
                class=3D"">On 10/13/2014 07:07 PM, Matthew Woehlke wrote:<b=
r>
                <br>
                <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  2. Doesn't std::expected throw if you try to
                  dereference it and it is<br>
                  "disengaged" (or whatever is the terminology)? What
                  I'm thinking is, do<br>
                  we even *need* throwing flavors, or can we just use
                  std::expected and<br>
                  fold the two together?<br>
                </blockquote>
                <br>
              </span>
              It should be possible to fold them together. You get an
              exception if<br>
              you call value() on an expected object that contains an
              unexpected<br>
              value, so this will throw on error:<br>
              <br>
              =C2=A0 auto size =3D file_size(p).value();<br>
              <br>
              Unfortunately you get a bad_expected_access&lt;E&gt;
              exception rather than<br>
              a system_error or filesystem_error. It is still unresolved
              how you get<br>
              another type of exception, but there are several
              discussions about it<br>
              in the expected proposal (e.g. section 7.2, 7.4, 7.5, and
              7.8 in N4015.)
              <div class=3D"HOEnZb">
                <div class=3D"h5"><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
        <div class=3D"gmail_extra">IIRC, expected&lt;T,E&gt; will throw E
          (instead of bad_expected_access) if E is derived from
          std::exception.=C2=A0 (Or maybe that changed from the first versi=
on
          of expected&lt;&gt;?)<br>
        </div>
      </div>
    </blockquote>
    It's still under discussion, we first thought of an
    expected_traits&lt;E&gt;::bad_access function called in this
    particular case. The trait is specialized (by default) for
    std::exception_ptr, and error_condition/code. Which is proposed in
    the section 8.2 of N4109. The implementation is a step further and
    try to implement a more general solution in term of monads.<br>
    <br>
    There is endless discussion about expected and, IMHO, it shows that
    it's hard to incorporate functional features into C++, such as monad
    in this case. The problem being that doing that in a backward
    compatible way is extremely difficult. Anyways, with expected we
    show that it is possible to merge the two worlds. If you return an
    expected, the user is able to choose if he wants to use exception
    (by calling value()) or to use the functional paradigm (with
    then/map/...). Note that it is possible to make expected
    exception-free if you customize the trait in this way.<br>
    <br>
    The major argument against expected is that some people think that
    we should stick to exception to handle errors, so no more than one
    "official" way would be provided. With languages becoming more and
    more multi-paradigm, I don't think that being too conservative is
    the way to go.<br>
    <br>
    Pierre<br>
    <blockquote
cite=3D"mid:CAOHCbisTaT83VmW8jZCwvejU_n4UGtK=3D-rjgXzwsHNy3H=3DTVNQ@mail.gm=
ail.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div class=3D"gmail_extra"><br>
        </div>
        <div class=3D"gmail_extra">Tony<br>
          <br>
        </div>
      </div>
      -- <br>
      <br>
      --- <br>
      You received this message because you are subscribed to the Google
      Groups "ISO C++ Standard - Future Proposals" group.<br>
      To unsubscribe from this group and stop receiving emails from it,
      send an email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
      To post to this group, send email to <a moz-do-not-send=3D"true"
        href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</=
a>.<br>
      Visit this group at <a moz-do-not-send=3D"true"
        href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
    </blockquote>
    <br>
  </body>
</html>

<p></p>

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

--------------070202050005090308060103--

.

On 10/14/2014 04:41 PM, Tony V E wrote:

>     Unfortunately you get a bad_expected_access<E> exception rather than
>     a system_error or filesystem_error. It is still unresolved how you get
>     another type of exception, but there are several discussions about it
>     in the expected proposal (e.g. section 7.2, 7.4, 7.5, and 7.8 in N4015.)
>
>
> IIRC, expected<T,E> will throw E (instead of bad_expected_access) if E
> is derived from std::exception.  (Or maybe that changed from the first
> version of expected<>?)

That is still the case (for E = expection_ptr.)

We could request a specialization for E = error_code to throw
system_error on bad access.

--

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

.

On Tuesday 14 October 2014 19:51:59 Miro Knejp wrote:
> Considering the overloads, we already have nothrow_t and nothrow, so
> hypothetically one could use this tag to distinguish the signatures as
> is done with new.
>
> auto size = file_size(p); // throw on error
> auto size = file_size(p, nothrow); // Returns optional/expected/whathaveyou

That would create a duplication of everything. The function that contains a
call to file_size() needs to be duplicated for throwing and nothrowing case.

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

--

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

.

On 2014-10-15 05:52, Pierre Talbot wrote:
> The major argument against expected is that some people think that we
> should stick to exception to handle errors, so no more than one
> "official" way would be provided. With languages becoming more and more
> multi-paradigm, I don't think that being too conservative is the way to go.

Yeah, um... that's a terrible argument IMHO. There are all kinds of
reasons people don't want to have to deal with exceptions. (Personally I
find that they're a ton of boilerplate for something that could be
handled in a much more efficient manner. std::expected is a great tool
for implementing that "more efficient manner".)

--
Matthew

--

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

.

Am 15.10.2014 um 15:20 schrieb Thiago Macieira:
> On Tuesday 14 October 2014 19:51:59 Miro Knejp wrote:
>> Considering the overloads, we already have nothrow_t and nothrow, so
>> hypothetically one could use this tag to distinguish the signatures as
>> is done with new.
>>
>> auto size = file_size(p); // throw on error
>> auto size = file_size(p, nothrow); // Returns optional/expected/whathaveyou
> That would create a duplication of everything. The function that contains a
> call to file_size() needs to be duplicated for throwing and nothrowing case.
>
That's how Boost.Filesystem works right now providing overloads with and
without error_code& for all calls that can produce errors. So yes, in a
library one probably should provide both, but in application code you
should know whether you want the throwing behavior or not.

--

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

.

On Wednesday 15 October 2014 20:22:02 Miro Knejp wrote:
> That's how Boost.Filesystem works right now providing overloads with and
> without error_code& for all calls that can produce errors. So yes, in a
> library one probably should provide both, but in application code you
> should know whether you want the throwing behavior or not.

Libraries are a much bigger footprint of a device's code than the application.
Taken to extreme, the use of overloads would mean the libraries are twice as
big as they need to be.

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

--

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

.

------=_Part_983_1834933634.1413405162247
Content-Type: text/plain; charset=UTF-8



On Thursday, October 16, 2014 9:24:18 AM UTC+13, Thiago Macieira wrote:
>
> On Wednesday 15 October 2014 20:22:02 Miro Knejp wrote:
> > That's how Boost.Filesystem works right now providing overloads with and
> > without error_code& for all calls that can produce errors. So yes, in a
> > library one probably should provide both, but in application code you
> > should know whether you want the throwing behavior or not.
>
> Libraries are a much bigger footprint of a device's code than the
> application.
> Taken to extreme, the use of overloads would mean the libraries are twice
> as
> big as they need to be.
>
> Let us please have std::expected...
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>
A Class for Status and Optional Value
ISO/IEC JTC1 SC22 WG21 N4233 - 2014-10-10

Seems of relevance to this discussion?

--

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

<div dir=3D"ltr"><br><br>On Thursday, October 16, 2014 9:24:18 AM UTC+13, T=
hiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;">On Wednesday 15 October 2=
014 20:22:02 Miro Knejp wrote:
<br>&gt; That's how Boost.Filesystem works right now providing overloads wi=
th and=20
<br>&gt; without error_code&amp; for all calls that can produce errors. So =
yes, in a=20
<br>&gt; library one probably should provide both, but in application code =
you=20
<br>&gt; should know whether you want the throwing behavior or not.
<br>
<br>Libraries are a much bigger footprint of a device's code than the appli=
cation.=20
<br>Taken to extreme, the use of overloads would mean the libraries are twi=
ce as=20
<br>big as they need to be.
<br>
<br>Let us please have std::expected...
<br>--=20
<br>Thiago Macieira - thiago (AT) <a onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\07=
51\46usg\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;" href=3D"http:/=
/macieira.info" target=3D"_blank">macieira.info</a> - thiago (AT) <a onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org\46=
sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.or=
g\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return t=
rue;" href=3D"http://kde.org" target=3D"_blank">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote><div><br></div><div>A Class for Status and Optional Value<=
/div><div>ISO/IEC JTC1 SC22 WG21 N4233 - 2014-10-10 </div><div><br></div><d=
iv><div>Seems of relevance to this discussion?</div></div></div>

<p></p>

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

------=_Part_983_1834933634.1413405162247--

.

Am 15.10.2014 um 22:23 schrieb Thiago Macieira:
> On Wednesday 15 October 2014 20:22:02 Miro Knejp wrote:
>> That's how Boost.Filesystem works right now providing overloads with and
>> without error_code& for all calls that can produce errors. So yes, in a
>> library one probably should provide both, but in application code you
>> should know whether you want the throwing behavior or not.
> Libraries are a much bigger footprint of a device's code than the application.
> Taken to extreme, the use of overloads would mean the libraries are twice as
> big as they need to be.
>
> Let us please have std::expected...
No disagreement there, I was merely commenting on the mentioned overload
ambiguity.

--

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

.

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

Agreed. One of C++'s core design principles (and greatest strengths) is
that it is a multi-paradigm language. To now insist that there must be One
True Paradigm for error handling would be unprecedented enough, but to
insist that it be _exceptions_, probably the most frequently disabled
feature in the language, would just be perverse.
On Oct 15, 2014 9:04 AM, "Matthew Woehlke" <mw_triad@users.sourceforge.net>
wrote:

> On 2014-10-15 05:52, Pierre Talbot wrote:
> > The major argument against expected is that some people think that we
> > should stick to exception to handle errors, so no more than one
> > "official" way would be provided. With languages becoming more and more
> > multi-paradigm, I don't think that being too conservative is the way to
> go.
>
> Yeah, um... that's a terrible argument IMHO. There are all kinds of
> reasons people don't want to have to deal with exceptions. (Personally I
> find that they're a ton of boilerplate for something that could be
> handled in a much more efficient manner. std::expected is a great tool
> for implementing that "more efficient manner".)
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<p dir=3D"ltr">Agreed. One of C++&#39;s core design principles (and greates=
t strengths) is that it is a multi-paradigm language. To now insist that th=
ere must be One True Paradigm for error handling would be unprecedented eno=
ugh, but to insist that it be _exceptions_, probably the most frequently di=
sabled feature in the language, would just be perverse.</p>
<div class=3D"gmail_quote">On Oct 15, 2014 9:04 AM, &quot;Matthew Woehlke&q=
uot; &lt;<a href=3D"mailto:mw_triad@users.sourceforge.net">mw_triad@users.s=
ourceforge.net</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">On 2014-10-15 05:52, Pierre Talbot wrote:<br>
&gt; The major argument against expected is that some people think that we<=
br>
&gt; should stick to exception to handle errors, so no more than one<br>
&gt; &quot;official&quot; way would be provided. With languages becoming mo=
re and more<br>
&gt; multi-paradigm, I don&#39;t think that being too conservative is the w=
ay to go.<br>
<br>
Yeah, um... that&#39;s a terrible argument IMHO. There are all kinds of<br>
reasons people don&#39;t want to have to deal with exceptions. (Personally =
I<br>
find that they&#39;re a ton of boilerplate for something that could be<br>
handled in a much more efficient manner. std::expected is a great tool<br>
for implementing that &quot;more efficient manner&quot;.)<br>
<br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

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

--001a11c12aa661c1000505828a4a--

.

On 10/15/2014 08:22 PM, Miro Knejp wrote:

> That's how Boost.Filesystem works right now providing overloads with and
> without error_code& for all calls that can produce errors. So yes, in a

The same is happening with the network proposal (N4243.)

--

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



On Tuesday, October 14, 2014 6:37:34 AM UTC+13, Ville Voutilainen wrote:
>
> On 13 October 2014 20:07, Matthew Woehlke
> <mw_t...@users.sourceforge.net <javascript:>> wrote:
> > 1. Yes, please use std::expected.
>
> You people seriously need to hold your horses. expected is nowhere near
> being
> std::expected, so filesystem cannot use it yet. IF expected gets accepted,
> then
> the API of filesystem can consider using it, but not before.
>

When you say "cannot" here, I don't know if you mean it's not possible,
or not likely?
I'm thinking filesystem should use the expected library and sooner than
later If possible.
If that means a sharp focus on std::expected, what better way to get
that/test than to use expected in filesystem....

A good discussion about the value of expected in the context of
filesystem might help the expected proposal move faster.
So in that light, perhaps holding horses isn't the best thing?

--

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

<div dir=3D"ltr"><br><br>On Tuesday, October 14, 2014 6:37:34 AM UTC+13, Vi=
lle Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); =
border-left-width: 1px; border-left-style: solid;">On 13 October 2014 20:07=
, Matthew Woehlke
<br>&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"0O00jEp7RcUJ">mw_t...@users.sourceforge.<w=
br>net</a>&gt; wrote:
<br>&gt; 1. Yes, please use std::expected.
<br>
<br>You people seriously need to hold your horses. expected is nowhere near=
 being
<br>std::expected, so filesystem cannot use it yet. IF expected gets accept=
ed, then
<br>the API of filesystem can consider using it, but not before.
<br></blockquote><div><br></div><div>When you say "cannot"&nbsp;here, I don=
't know if you mean&nbsp;it's not possible, or&nbsp;not likely?</div><div>I=
'm&nbsp;thinking filesystem should use the expected library and sooner than=
 later If possible.</div><div>If that means a sharp focus on std::expected,=
 what better way to get that/test than&nbsp;to use&nbsp;expected in filesys=
tem....</div><div><br></div><div>A&nbsp;good discussion about the value of =
expected in the context of filesystem&nbsp;might help&nbsp;the expected pro=
posal move faster.</div><div>So in that light, perhaps holding horses isn't=
 the best thing?</div></div>

<p></p>

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

------=_Part_6411_913635959.1413464864669--

.

On 16 October 2014 16:07,  <gmisocpp@gmail.com> wrote:
> On Tuesday, October 14, 2014 6:37:34 AM UTC+13, Ville Voutilainen wrote:
>> You people seriously need to hold your horses. expected is nowhere near
>> being
>> std::expected, so filesystem cannot use it yet. IF expected gets accepted,
>> then
>> the API of filesystem can consider using it, but not before.
> When you say "cannot" here, I don't know if you mean it's not possible, or
> not likely?

I mean what I said - from the point of view of the Filesystem TS, expected
does not exist. It's not in any TS, in any standard, or even in any draft.

> I'm thinking filesystem should use the expected library and sooner than
> later If possible.

That remains to be seen. The suggestion of always returning expected
seem premature to me, because that also incurs a potential return object
size overhead for the current cases that may throw.

People should also remember that the Filesystem TS is under its final
publication
ballot, so changing the first version of that TS at this point
requires a national
body comment.

--

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

.