------=_Part_206_9651485.1404864382757
Content-Type: text/plain; charset=UTF-8

The N4109 paper section 6.3.1 addresses the question of the default
constructor behavior for an expected<T,E>.

One option that is not presented is to make expected<T,E> default construct
as with T{} iff T is default constructable and to delete expected's default
constructor iff T is not default constructable. The implementation is a bit
trickier but the end semantics are IMHO cleaner. Default constructing as
expected<T,E>{make_unexpected(E{})} has the safety and misuse concerns
already laid out in the paper, but personally I'm not seeing a strong use
case to ever default-construct an expected when the primary type T is
cannot itself be default constructed.

Another reason for this is that I suspect many users will be using enums or
POSIX-like error codes as the E type parameter with 0 meaning "all OK."
This would result in expected<T,E>{} using the paper's proposed rules
encapsulating a very odd and meaningless object that is in an error-state
(it has an unexpected<E> but no T) but the actual error code indicates
there isn't a problem. This would conceptually violate a semantic
invariant, at least in my mind.

Summary: the default constructor for expected should default-construct its
value T rather than E and expected should have a deleted default
constructor if T is not default constructable.

--

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

<div dir=3D"ltr">The N4109 paper section 6.3.1 addresses the question of th=
e default constructor behavior for an expected&lt;T,E&gt;.<div><br></div><d=
iv>One option that is not presented is to make expected&lt;T,E&gt; default =
construct as with T{} iff T is default constructable and to delete expected=
's default constructor iff T is not default constructable. The implementati=
on is a bit trickier but the end semantics are IMHO cleaner. Default constr=
ucting as expected&lt;T,E&gt;{make_unexpected(E{})} has the safety and misu=
se concerns already laid out in the paper, but personally I'm not seeing a =
strong use case to ever default-construct an expected when the primary type=
 T is cannot itself be default constructed.<br></div><div><br></div><div>An=
other reason for this is that I suspect many users will be using enums or P=
OSIX-like error codes as the E type parameter with 0 meaning "all OK." This=
 would result in expected&lt;T,E&gt;{} using the paper's proposed rules enc=
apsulating a very odd and meaningless object that is in an error-state (it =
has an unexpected&lt;E&gt; but no T) but the actual error code indicates th=
ere isn't a problem. This would conceptually violate a semantic invariant, =
at least in my mind.</div><div><br></div><div>Summary: the default construc=
tor for expected should default-construct its value T rather than E and exp=
ected should have a deleted default constructor if T is not default constru=
ctable.</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_206_9651485.1404864382757--

.

I fixed the rational in 6.3.1 with:

"Unlike optional<T>, the goal of expected is not to provide a wrapper=20
for types that are not defaultconstructible.
Hence, the authors consider that expected<T,E> should have a default=20
constructor if and only if
T is default-constructible, and if so, default construct to T{}. If T is=20
not default constructible, the user will be
free to wrap it inside an optional (expected<optional<T>, E>)."

The wording in section 9 (X.Y.9.1 Constructors) was already stating this=20
idea:

constexpr expected() noexcept(=E2=80=99see below=E2=80=99);

Effects:
     Initializes the contained value as if direct-non-list-initializing=20
an object of type T with the expression T().
[snip]
Remarks:
     This signature shall not participate in overload resolution unless=20
is_default_constructible<T>::value.


Thanks for raising this incoherence.

Pierre Talbot

PS: Last updated PDF at http://www.hyc.io/boost/expected-proposal.pdf
       Repository at https://github.com/ptal/std-expected-proposal

On 07/09/2014 02:06 AM, Sean Middleditch wrote:
> The N4109 paper section 6.3.1 addresses the question of the default=20
> constructor behavior for an expected<T,E>.
>
> One option that is not presented is to make expected<T,E> default=20
> construct as with T{} iff T is default constructable and to delete=20
> expected's default constructor iff T is not default constructable. The=20
> implementation is a bit trickier but the end semantics are IMHO=20
> cleaner. Default constructing as expected<T,E>{make_unexpected(E{})}=20
> has the safety and misuse concerns already laid out in the paper, but=20
> personally I'm not seeing a strong use case to ever default-construct=20
> an expected when the primary type T is cannot itself be default=20
> constructed.
>
> Another reason for this is that I suspect many users will be using=20
> enums or POSIX-like error codes as the E type parameter with 0 meaning=20
> "all OK." This would result in expected<T,E>{} using the paper's=20
> proposed rules encapsulating a very odd and meaningless object that is=20
> in an error-state (it has an unexpected<E> but no T) but the actual=20
> error code indicates there isn't a problem. This would conceptually=20
> violate a semantic invariant, at least in my mind.
>
> Summary: the default constructor for expected should default-construct=20
> its value T rather than E and expected should have a deleted default=20
> constructor if T is not default constructable.
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> Visit this group at=20
> 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/.

.

Le 09/07/14 09:08, Pierre Talbot a =C3=A9crit :
> I fixed the rational in 6.3.1 with:
>
> "Unlike optional<T>, the goal of expected is not to provide a wrapper=20
> for types that are not defaultconstructible.
> Hence, the authors consider that expected<T,E> should have a default=20
> constructor if and only if
> T is default-constructible, and if so, default construct to T{}. If T=20
> is not default constructible, the user will be
> free to wrap it inside an optional (expected<optional<T>, E>)."
>
> The wording in section 9 (X.Y.9.1 Constructors) was already stating=20
> this idea:
>
> constexpr expected() noexcept(=E2=80=99see below=E2=80=99);
>
> Effects:
>     Initializes the contained value as if direct-non-list-initializing=20
> an object of type T with the expression T().
> [snip]
> Remarks:
>     This signature shall not participate in overload resolution unless=20
> is_default_constructible<T>::value.
>
>
> Thanks for raising this incoherence.
>
IMO, the original design was to initialize it with make_unexpected(E{}).=20
Changing to T{} must be described in a specific paper as a change.
> Pierre Talbot
>
> PS: Last updated PDF at http://www.hyc.io/boost/expected-proposal.pdf
>       Repository at https://github.com/ptal/std-expected-proposal
>
Pierre, please don't publish new versions without changing the doc=20
number. In this case it should be again be DXXXX.

Best,
Vicente

> On 07/09/2014 02:06 AM, Sean Middleditch wrote:
>> The N4109 paper section 6.3.1 addresses the question of the default=20
>> constructor behavior for an expected<T,E>.
>>
>> One option that is not presented is to make expected<T,E> default=20
>> construct as with T{} iff T is default constructable and to delete=20
>> expected's default constructor iff T is not default constructable.=20
>> The implementation is a bit trickier but the end semantics are IMHO=20
>> cleaner. Default constructing as expected<T,E>{make_unexpected(E{})}=20
>> has the safety and misuse concerns already laid out in the paper, but=20
>> personally I'm not seeing a strong use case to ever default-construct=20
>> an expected when the primary type T is cannot itself be default=20
>> constructed.
>>
>> Another reason for this is that I suspect many users will be using=20
>> enums or POSIX-like error codes as the E type parameter with 0=20
>> meaning "all OK." This would result in expected<T,E>{} using the=20
>> paper's proposed rules encapsulating a very odd and meaningless=20
>> object that is in an error-state (it has an unexpected<E> but no T)=20
>> but the actual error code indicates there isn't a problem. This would=20
>> conceptually violate a semantic invariant, at least in my mind.
>>
>> Summary: the default constructor for expected should=20
>> default-construct its value T rather than E and expected should have=20
>> a deleted default constructor if T is not default constructable.
>> --=20
>>
>> ---
>> You received this message because you are subscribed to the Google=20
>> Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it,=20
>> send an email to std-proposals+unsubscribe@isocpp.org=20
>> <mailto:std-proposals+unsubscribe@isocpp.org>.
>> To post to this group, send email to std-proposals@isocpp.org=20
>> <mailto:std-proposals@isocpp.org>.
>> Visit this group at=20
>> 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/.

.

On 11 July 2014 13:51, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
>> PS: Last updated PDF at http://www.hyc.io/boost/expected-proposal.pdf
>>       Repository at https://github.com/ptal/std-expected-proposal
>>
> Pierre, please don't publish new versions without changing the doc number.
> In this case it should be again be DXXXX.


A reminder of the ground rules:
1) never, EVER, modify a document with an N-number after it's been
published, including
in public version control repositories
2) if you need to publish working versions, use a D-number, or no
number at all, like the XXXX
above.

--

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

.

Le 09/07/14 02:06, Sean Middleditch a =C3=A9crit :
> The N4109 paper section 6.3.1 addresses the question of the default=20
> constructor behavior for an expected<T,E>.
>
> One option that is not presented is to make expected<T,E> default=20
> construct as with T{} iff T is default constructable and to delete=20
> expected's default constructor iff T is not default constructable. The=20
> implementation is a bit trickier but the end semantics are IMHO=20
> cleaner. Default constructing as expected<T,E>{make_unexpected(E{})}=20
> has the safety and misuse concerns already laid out in the paper, but=20
> personally I'm not seeing a strong use case to ever default-construct=20
> an expected when the primary type T is cannot itself be default=20
> constructed.
We had two goals, to make expected<T,E> to behave as much as possible as=20
T and expected<T,nulopt_t> to behave as much as possible as optional<T>.=20
These goals are in contradiction when we consider default construction.
Now that we have switched the order of parameters, expected<T,E> should=20
behave as much as possible as variant<T,E>.
>
> Another reason for this is that I suspect many users will be using=20
> enums or POSIX-like error codes as the E type parameter with 0 meaning=20
> "all OK." This would result in expected<T,E>{} using the paper's=20
> proposed rules encapsulating a very odd and meaningless object that is=20
> in an error-state (it has an unexpected<E> but no T) but the actual=20
> error code indicates there isn't a problem. This would conceptually=20
> violate a semantic invariant, at least in my mind.

Yes, this is unfortunate. The same invariant is violated when you do

expected<T,E> iv =3D make_unexpected(E{});

There is a hidden constraint on E: all the values of E are considered as=20
errors.
>
> Summary: the default constructor for expected should default-construct=20
> its value T rather than E and expected should have a deleted default=20
> constructor if T is not default constructable.
Default construction to T{} has  the advantage to avoid the issue with a=20
defaulted expected<T,exception_ptr>, that needs to create an artificial=20
exception to be throw when calling value().

If no body is against, we could add this alternative to the rationale on=20
6.3.1 and add a new open point with the raised issues.

Thanks a lot for the rationale and the possible new direction.

What others think about this alternative default constructor?

Vicente

--=20

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

.

On 07/11/2014 04:31 PM, Ville Voutilainen wrote:
> On 11 July 2014 13:51, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>>> PS: Last updated PDF at http://www.hyc.io/boost/expected-proposal.pdf
>>>        Repository at https://github.com/ptal/std-expected-proposal
>>>
>> Pierre, please don't publish new versions without changing the doc number.
>> In this case it should be again be DXXXX.
>
> A reminder of the ground rules:
> 1) never, EVER, modify a document with an N-number after it's been
> published, including
> in public version control repositories
> 2) if you need to publish working versions, use a D-number, or no
> number at all, like the XXXX
> above.
>
OK, my mistake, sorry for the noise it generated.

--

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

.