Topic: Interest in a status-or-value proposal?


Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Tue, 26 Mar 2013 10:36:20 -0400
Raw View
--047d7b3a8c5c4ef66604d8d4d891
Content-Type: text/plain; charset=ISO-8859-1

In the thread discussing N3533 (Concurrent Queues), Lawrence Crowl brought
up the idea of a type that carries either a status or a value, and noted
that no concrete proposal existed. I'd perhaps be interested in working on
such a proposal. Does anyone have references to any of the prior discussion?

I'd also be interested in any background on proposals, historical or
current, to define std::variant<...> or std::either<T, U>, as adoption of
either of those would lead to any number of trivial implementations of a
'status-or-value' concept:

template<typename T>
using error_condition_or = std::either<std::error_condition, T>;

In that case I'm not sure that a separate proposal would be helpful.

--

---
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/?hl=en.



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

<div dir=3D"ltr"><br><div style>In the thread discussing N3533 (Concurrent =
Queues), Lawrence Crowl brought up the idea of a type that carries either a=
 status or a value, and noted that no concrete proposal existed. I&#39;d pe=
rhaps be interested in working on such a proposal. Does anyone have referen=
ces to any of the prior discussion?</div>
<div style><br></div><div style>I&#39;d also be interested in any backgroun=
d on proposals, historical or current, to define=A0<font face=3D"courier ne=
w, monospace">std::variant&lt;...&gt;</font>=A0or <font face=3D"courier new=
, monospace">std::either&lt;T, U&gt;</font>, as adoption of either of those=
 would lead to any number of trivial implementations of a &#39;status-or-va=
lue&#39; concept:</div>
<div style><br></div><div style><font face=3D"courier new, monospace">templ=
ate&lt;typename T&gt;</font></div><div style><font face=3D"courier new, mon=
ospace">using error_condition_or =3D std::either&lt;std::error_condition, T=
&gt;;</font></div>
<div style><br></div><div style>In that case I&#39;m not sure that a separa=
te proposal would be helpful.</div><div style><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--047d7b3a8c5c4ef66604d8d4d891--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 26 Mar 2013 16:38:14 +0200
Raw View
On 26 March 2013 16:36, Andrew C. Morrow <andrew.c.morrow@gmail.com> wrote:
>
> In the thread discussing N3533 (Concurrent Queues), Lawrence Crowl brought
> up the idea of a type that carries either a status or a value, and noted
> that no concrete proposal existed. I'd perhaps be interested in working on
> such a proposal. Does anyone have references to any of the prior discussion?
> I'd also be interested in any background on proposals, historical or
> current, to define std::variant<...> or std::either<T, U>, as adoption of
> either of those would lead to any number of trivial implementations of a
> 'status-or-value' concept:
> template<typename T>
> using error_condition_or = std::either<std::error_condition, T>;
> In that case I'm not sure that a separate proposal would be helpful.

I would think boost::variant would be a good candidate, but there
hasn't been anyone with enough
time on their hands to propose it. We have proposals for any and
optional, but not for variant.

--

---
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/?hl=en.



.


Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Tue, 26 Mar 2013 08:31:50 -0700 (PDT)
Raw View
------=_Part_364_33351936.1364311910703
Content-Type: text/plain; charset=ISO-8859-1

On Tuesday, March 26, 2013 3:36:20 PM UTC+1, Andrew Morrow wrote:

>
> In the thread discussing N3533 (Concurrent Queues), Lawrence Crowl brought
> up the idea of a type that carries either a status or a value, and noted
> that no concrete proposal existed. I'd perhaps be interested in working on
> such a proposal. Does anyone have references to any of the prior discussion?
>
> I'd also be interested in any background on proposals, historical or
> current, to define std::variant<...> or std::either<T, U>, as adoption of
> either of those would lead to any number of trivial implementations of a
> 'status-or-value' concept:
>
>
Andrei Alexandrescu <http://en.wikipedia.org/wiki/Andrei_Alexandrescu>
gave a presentation about error handling, including a valur-or-error
concept.

--

---
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/?hl=en.



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

On Tuesday, March 26, 2013 3:36:20 PM UTC+1, Andrew Morrow wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>In the thr=
ead discussing N3533 (Concurrent Queues), Lawrence Crowl brought up the ide=
a of a type that carries either a status or a value, and noted that no conc=
rete proposal existed. I'd perhaps be interested in working on such a propo=
sal. Does anyone have references to any of the prior discussion?</div>
<div><br></div><div>I'd also be interested in any background on proposals, =
historical or current, to define&nbsp;<font face=3D"courier new, monospace"=
>std::variant&lt;...&gt;</font>&nbsp;or <font face=3D"courier new, monospac=
e">std::either&lt;T, U&gt;</font>, as adoption of either of those would lea=
d to any number of trivial implementations of a 'status-or-value' concept:<=
/div>
<div><br></div></div></blockquote><div><br></div><div><a href=3D"http://en.=
wikipedia.org/wiki/Andrei_Alexandrescu" title=3D"Andrei Alexandrescu" style=
=3D"color: rgb(11, 0, 128); background-image: none; background-color: rgb(2=
49, 249, 249); font-family: sans-serif; font-size: 11px; line-height: 16.89=
0625px;">Andrei Alexandrescu</a><span style=3D"color: rgb(0, 0, 0); font-fa=
mily: sans-serif; font-size: 11px; line-height: 16.890625px; background-col=
or: rgb(249, 249, 249);">&nbsp; gave a presentation about error handling, i=
ncluding a valur-or-error concept.</span>&nbsp;</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_364_33351936.1364311910703--

.


Author: "Andrew C. Morrow" <andrew.c.morrow@gmail.com>
Date: Tue, 26 Mar 2013 12:07:09 -0400
Raw View
--f46d044284f815990404d8d61d7c
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Mar 26, 2013 at 11:31 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

> On Tuesday, March 26, 2013 3:36:20 PM UTC+1, Andrew Morrow wrote:
>
>>
>> In the thread discussing N3533 (Concurrent Queues), Lawrence Crowl
>> brought up the idea of a type that carries either a status or a value, and
>> noted that no concrete proposal existed. I'd perhaps be interested in
>> working on such a proposal. Does anyone have references to any of the prior
>> discussion?
>>
>> I'd also be interested in any background on proposals, historical or
>> current, to define std::variant<...> or std::either<T, U>, as adoption
>> of either of those would lead to any number of trivial implementations of a
>> 'status-or-value' concept:
>>
>>
> Andrei Alexandrescu <http://en.wikipedia.org/wiki/Andrei_Alexandrescu>
> gave a presentation about error handling, including a valur-or-error
> concept.
>
> --
>
>
I haven't seen Andrei's talk about Expected<T>, but I am aware of at least
two other C++ implementations, and other languages offer similar
facilities: Rust has Result<T,
E><http://static.rust-lang.org/doc/core/result.html#enum-result>,
Haskell
I believe uses Either for this, and I'm sure there are many others I'm not
familiar with.

--

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



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

<div dir=3D"ltr"><div style><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Tue, Mar 26, 2013 at 11:31 AM, Olaf van der Spek <span =
dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">o=
lafvdspek@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On Tuesday, March 26, 2013 3:36:20 PM UT=
C+1, Andrew Morrow wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><br><div>In the thread discussing N3533 (=
Concurrent Queues), Lawrence Crowl brought up the idea of a type that carri=
es either a status or a value, and noted that no concrete proposal existed.=
 I&#39;d perhaps be interested in working on such a proposal. Does anyone h=
ave references to any of the prior discussion?</div>

<div><br></div><div>I&#39;d also be interested in any background on proposa=
ls, historical or current, to define=A0<font face=3D"courier new, monospace=
">std::variant&lt;...&gt;</font>=A0or <font face=3D"courier new, monospace"=
>std::either&lt;T, U&gt;</font>, as adoption of either of those would lead =
to any number of trivial implementations of a &#39;status-or-value&#39; con=
cept:</div>

<div><br></div></div></blockquote><div><br></div></div><div><a href=3D"http=
://en.wikipedia.org/wiki/Andrei_Alexandrescu" title=3D"Andrei Alexandrescu"=
 style=3D"color:rgb(11,0,128);background-image:none;background-color:rgb(24=
9,249,249);font-family:sans-serif;font-size:11px;line-height:16.890625px" t=
arget=3D"_blank">Andrei Alexandrescu</a><span style=3D"line-height:16.89062=
5px;font-size:11px;background-color:rgb(249,249,249);font-family:sans-serif=
">=A0 gave a presentation about error handling, including a valur-or-error =
concept.</span>=A0</div>
<div class=3D""><div class=3D"h5">

<p></p>

-- <br><br></div></div></blockquote><div><br></div><div>I haven&#39;t seen =
Andrei&#39;s talk about Expected&lt;T&gt;, but I am aware of at least two o=
ther C++ implementations, and other languages offer similar facilities: Rus=
t has=A0<a href=3D"http://static.rust-lang.org/doc/core/result.html#enum-re=
sult">Result&lt;T, E&gt;</a>,=A0Haskell I believe uses Either for this, and=
 I&#39;m sure there are many others I&#39;m not familiar with.</div>
<div><br></div><div><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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

--f46d044284f815990404d8d61d7c--

.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 26 Mar 2013 21:07:43 +0100
Raw View
This is a multi-part message in MIME format.
--------------020609000204050809060001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 26/03/13 15:36, Andrew C. Morrow a =E9crit :
>
> In the thread discussing N3533 (Concurrent Queues), Lawrence Crowl=20
> brought up the idea of a type that carries either a status or a value,=20
> and noted that no concrete proposal existed. I'd perhaps be interested=20
> in working on such a proposal. Does anyone have references to any of=20
> the prior discussion?
>
> I'd also be interested in any background on proposals, historical or=20
> current, to define std::variant<...> or std::either<T, U>, as adoption=20
> of either of those would lead to any number of trivial implementations=20
> of a 'status-or-value' concept:
>
> template<typename T>
> using error_condition_or =3D std::either<std::error_condition, T>;
>
> In that case I'm not sure that a separate proposal would be helpful.
>
>
I don't see how the status or value could help the definition of the pop=20
concurrent queue function as I already said as I don't see how it can=20
ensure that is no throw copy movable.

Nevertheless a std::variant would be too much appreciated.

Best,
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/?hl=3Den.



--------------020609000204050809060001
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 26/03/13 15:36, Andrew C. Morrow a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
cite="mid:CA+Acj4ewSmiu247rW-dYeHVJ71YqPjtpYyD-4rjsVTJJ-85VFQ@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div style="">In the thread discussing N3533 (Concurrent
          Queues), Lawrence Crowl brought up the idea of a type that
          carries either a status or a value, and noted that no concrete
          proposal existed. I'd perhaps be interested in working on such
          a proposal. Does anyone have references to any of the prior
          discussion?</div>
        <div style=""><br>
        </div>
        <div style="">I'd also be interested in any background on
          proposals, historical or current, to define&nbsp;<font
            face="courier new, monospace">std::variant&lt;...&gt;</font>&nbsp;or
          <font face="courier new, monospace">std::either&lt;T, U&gt;</font>,
          as adoption of either of those would lead to any number of
          trivial implementations of a 'status-or-value' concept:</div>
        <div style=""><br>
        </div>
        <div style=""><font face="courier new, monospace">template&lt;typename
            T&gt;</font></div>
        <div style=""><font face="courier new, monospace">using
            error_condition_or = std::either&lt;std::error_condition,
            T&gt;;</font></div>
        <div style=""><br>
        </div>
        <div style="">In that case I'm not sure that a separate proposal
          would be helpful.</div>
        <div style=""><br>
        </div>
      </div>
      <br>
    </blockquote>
    I don't see how the status or value could help the definition of the
    pop concurrent queue function as I already said as I don't see how
    it can ensure that is no throw copy movable.<br>
    <br>
    Nevertheless a std::variant would be too much appreciated.<br>
    <br>
    Best,<br>
    Vicente<br>
  </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 email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--------------020609000204050809060001--

.


Author: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 26 Mar 2013 15:06:46 -0700
Raw View
On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Le 26/03/13 15:36, Andrew C. Morrow a =E9crit :
> > In the thread discussing N3533 (Concurrent Queues), Lawrence
> > Crowl brought up the idea of a type that carries either a status
> > or a value, and noted that no concrete proposal existed. I'd
> > perhaps be interested in working on such a proposal. Does anyone
> > have references to any of the prior discussion?
> >
> > I'd also be interested in any background on proposals, historical
> > or current, to define std::variant<...> or std::either<T, U>,
> > as adoption of either of those would lead to any number of
> > trivial implementations of a 'status-or-value' concept:
> >
> > template<typename T>
> > using error_condition_or =3D std::either<std::error_condition, T>;
> >
> > In that case I'm not sure that a separate proposal would
> > be helpful.
>
> I don't see how the status or value could help the definition of
> the pop concurrent queue function as I already said as I don't
> see how it can ensure that is no throw copy movable.
>
> Nevertheless a std::variant would be too much appreciated.

The intent was not to solve the move problem, but to reduce the
number of distinct operations.  So, instead of two functions used
like this

    v =3D queue.value_pop();

    s =3D queue.wait_pop(v);

you would have one operation used two ways

    v =3D queue.pop().value();

    sv =3D queue().pop();
    s =3D sv.status();
    v =3D sv.value();

Any call to value() when there is no value results in an exception.

This issue is going to keep coming back as we add more concurrency
features, because you cannot reliably test the status of the
operations separately from doing the operations.

A general facility here would be most helpful.

--=20
Lawrence Crowl

--=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/?hl=3Den.



.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 27 Mar 2013 00:09:55 +0100
Raw View
Le 26/03/13 23:06, Lawrence Crowl a =E9crit :
> The intent was not to solve the move problem, but to reduce the
> number of distinct operations.
Oh, I see. The pop prototype using status-or-value would be available=20
only for value type that no throw when moving.
> So, instead of two functions used
> like this
>
>      v =3D queue.value_pop();
>
>      s =3D queue.wait_pop(v);
>
> you would have one operation used two ways
>
>      v =3D queue.pop().value();
>
>      sv =3D queue().pop();
>      s =3D sv.status();
>      v =3D sv.value();
>
> Any call to value() when there is no value results in an exception.
It would be great if the status could be obtained from the exception thrown=
..
A conversion to bool should help also.
>
> This issue is going to keep coming back as we add more concurrency
> features, because you cannot reliably test the status of the
> operations separately from doing the operations.
>
> A general facility here would be most helpful.

I don't think variant<status, T> would be what the user expects in the=20
same way variant<bool, T> doesn't replace optional<T>.
The expected<T> utility from Andrei is quite close, but stores an=20
exception instead of an status.

Instead of returning a status-or-value, have you considered the Beman's=20
approach to add an additional error_code parameter? I know that this=20
kind of interfaces are C-ish, but if we want to avoid exception I=20
consider it a valid alternative, even if less elegant than=20
expected-or-error_code<T>.

Element queue::pop(std::error_code&);
expected-or-error_code<T> queue::pop_value();

Vicente

P.S. Have you consider renaming the push/pop/pop_value operations=20
enqueue/dequeue or push/pull?

--=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/?hl=3Den.



.


Author: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 26 Mar 2013 17:51:36 -0700
Raw View
On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Le 26/03/13 23:06, Lawrence Crowl a =E9crit :
> > The intent was not to solve the move problem, but to reduce the
> > number of distinct operations.
>
> Oh, I see. The pop prototype using status-or-value would be available
> only for value type that no throw when moving.

I think that is a separate issue from a status-or-value type.

> > So, instead of two functions used
> > like this
> >
> >      v =3D queue.value_pop();
> >
> >      s =3D queue.wait_pop(v);
> >
> > you would have one operation used two ways
> >
> >      v =3D queue.pop().value();
> >
> >      sv =3D queue().pop();
> >      s =3D sv.status();
> >      v =3D sv.value();
> >
> > Any call to value() when there is no value results in an exception.
>
> It would be great if the status could be obtained from the
> exception thrown.

I can see getting an exception instead of a value when calling
value(), but I don't see the value in getting the status any way
but directly and without exceptions.

> A conversion to bool should help also.

Would true mean that a value is present?  Or that the status
is success?  How would the wrapper know what value success is?

> > This issue is going to keep coming back as we add more concurrency
> > features, because you cannot reliably test the status of the
> > operations separately from doing the operations.
> >
> > A general facility here would be most helpful.
>
> I don't think variant<status, T> would be what the user expects
> in the same way variant<bool, T> doesn't replace optional<T>.
> The expected<T> utility from Andrei is quite close, but stores
> an exception instead of an status.

Agreed.

> Instead of returning a status-or-value, have you considered the
> Beman's approach to add an additional error_code parameter? I
> know that this kind of interfaces are C-ish, but if we want to
> avoid exception I consider it a valid alternative, even if less
> elegant than expected-or-error_code<T>.

I usually want the control flow to depend on the status, and so
I find the code more concise if the statement condition contains
the call.  E.g.

  if ( success !=3D wait_pop( v ) )
    abort();

> Element queue::pop(std::error_code&);
> expected-or-error_code<T> queue::pop_value();

The intent is to reduce the number of interface functions.

> P.S. Have you consider renaming the push/pop/pop_value operations
> enqueue/dequeue or push/pull?

We picked the names we did for maximum commonality with the existing
standard library.  (Were there was not a clear difference.)  As a
committee, we need to decide if that is the best approach.

--=20
Lawrence Crowl

--=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/?hl=3Den.



.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 27 Mar 2013 13:39:54 +0100
Raw View
Le 27/03/13 01:51, Lawrence Crowl a =E9crit :
> On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
>> Le 26/03/13 23:06, Lawrence Crowl a =E9crit :
>>> The intent was not to solve the move problem, but to reduce the
>>> number of distinct operations.
>> Oh, I see. The pop prototype using status-or-value would be available
>> only for value type that no throw when moving.
> I think that is a separate issue from a status-or-value type.
Agreed.
>
>>> So, instead of two functions used
>>> like this
>>>
>>>       v =3D queue.value_pop();
>>>
>>>       s =3D queue.wait_pop(v);
>>>
>>> you would have one operation used two ways
>>>
>>>       v =3D queue.pop().value();
>>>
>>>       sv =3D queue().pop();
>>>       s =3D sv.status();
>>>       v =3D sv.value();
>>>
>>> Any call to value() when there is no value results in an exception.
>> It would be great if the status could be obtained from the
>> exception thrown.
> I can see getting an exception instead of a value when calling
> value(), but I don't see the value in getting the status any way
> but directly and without exceptions.
Well, if there is an exception the catch block could be interested in=20
knowing why.

What I want is

T expected_or_error_code<T>::value();

Return: return the stored value (if one).
Throws: system_error with the stored error_code if there is no value.=20
Any exception thrown by the T move constructor.
>
>> A conversion to bool should help also.
> Would true mean that a value is present?  Or that the status
> is success?  How would the wrapper know what value success is?
That the value is present.
>
>> Instead of returning a status-or-value, have you considered the
>> Beman's approach to add an additional error_code parameter? I
>> know that this kind of interfaces are C-ish, but if we want to
>> avoid exception I consider it a valid alternative, even if less
>> elegant than expected-or-error_code<T>.
> I usually want the control flow to depend on the status, and so
> I find the code more concise if the statement condition contains
> the call.  E.g.
>
>    if ( success !=3D wait_pop( v ) )
>      abort();
>
>> Element queue::pop(std::error_code&);
>> expected-or-error_code<T> queue::pop_value();
> The intent is to reduce the number of interface functions.
>
>
I know, I just wanted to present different alternatives.

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/?hl=3Den.



.


Author: Lawrence Crowl <crowl@googlers.com>
Date: Wed, 27 Mar 2013 18:19:46 -0700
Raw View
On 3/27/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Le 27/03/13 01:51, Lawrence Crowl a =E9crit :
>> On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
>>> Le 26/03/13 23:06, Lawrence Crowl a =E9crit :
>>>> The intent was not to solve the move problem, but to reduce the
>>>> number of distinct operations.
>>> Oh, I see. The pop prototype using status-or-value would be available
>>> only for value type that no throw when moving.
>> I think that is a separate issue from a status-or-value type.
> Agreed.
>>
>>>> So, instead of two functions used
>>>> like this
>>>>
>>>>       v =3D queue.value_pop();
>>>>
>>>>       s =3D queue.wait_pop(v);
>>>>
>>>> you would have one operation used two ways
>>>>
>>>>       v =3D queue.pop().value();
>>>>
>>>>       sv =3D queue().pop();
>>>>       s =3D sv.status();
>>>>       v =3D sv.value();
>>>>
>>>> Any call to value() when there is no value results in an exception.
>>> It would be great if the status could be obtained from the
>>> exception thrown.
>> I can see getting an exception instead of a value when calling
>> value(), but I don't see the value in getting the status any way
>> but directly and without exceptions.
> Well, if there is an exception the catch block could be interested in
> knowing why.
>
> What I want is
>
> T expected_or_error_code<T>::value();
>
> Return: return the stored value (if one).
> Throws: system_error with the stored error_code if there is no value.
> Any exception thrown by the T move constructor.

I'm okay with that.  I'm trying to say is that I want

U expected_or_error_code<U,T>::status() nothrow;

>>> A conversion to bool should help also.
>> Would true mean that a value is present?  Or that the status
>> is success?  How would the wrapper know what value success is?
> That the value is present.

So, in your approach would the status type have a success value
or not?

>>> Instead of returning a status-or-value, have you considered the
>>> Beman's approach to add an additional error_code parameter? I
>>> know that this kind of interfaces are C-ish, but if we want to
>>> avoid exception I consider it a valid alternative, even if less
>>> elegant than expected-or-error_code<T>.
>> I usually want the control flow to depend on the status, and so
>> I find the code more concise if the statement condition contains
>> the call.  E.g.
>>
>>    if ( success !=3D wait_pop( v ) )
>>      abort();
>>
>>> Element queue::pop(std::error_code&);
>>> expected-or-error_code<T> queue::pop_value();
>> The intent is to reduce the number of interface functions.
>>
>>
> I know, I just wanted to present different alternatives.

--=20
Lawrence Crowl

--=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/?hl=3Den.



.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 28 Mar 2013 07:56:59 +0100
Raw View
Le 28/03/13 02:19, Lawrence Crowl a =E9crit :
> On 3/27/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
>> Le 27/03/13 01:51, Lawrence Crowl a =E9crit :
>>> On 3/26/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
>>>> Le 26/03/13 23:06, Lawrence Crowl a =E9crit :
>>>>> The intent was not to solve the move problem, but to reduce the
>>>>> number of distinct operations.
>>>> Oh, I see. The pop prototype using status-or-value would be available
>>>> only for value type that no throw when moving.
>>> I think that is a separate issue from a status-or-value type.
>> Agreed.
>>>>> So, instead of two functions used
>>>>> like this
>>>>>
>>>>>        v =3D queue.value_pop();
>>>>>
>>>>>        s =3D queue.wait_pop(v);
>>>>>
>>>>> you would have one operation used two ways
>>>>>
>>>>>        v =3D queue.pop().value();
>>>>>
>>>>>        sv =3D queue().pop();
>>>>>        s =3D sv.status();
>>>>>        v =3D sv.value();
>>>>>
>>>>> Any call to value() when there is no value results in an exception.
>>>> It would be great if the status could be obtained from the
>>>> exception thrown.
>>> I can see getting an exception instead of a value when calling
>>> value(), but I don't see the value in getting the status any way
>>> but directly and without exceptions.
>> Well, if there is an exception the catch block could be interested in
>> knowing why.
>>
>> What I want is
>>
>> T expected_or_error_code<T>::value();
>>
>> Return: return the stored value (if one).
>> Throws: system_error with the stored error_code if there is no value.
>> Any exception thrown by the T move constructor.
> I'm okay with that.
Great.
> I'm trying to say is that I want
>
> U expected_or_error_code<U,T>::status() nothrow;
Oh, are you saying that what you need is the value and the status=20
(expected_*and*_error_code ), or that there is a specific U value that=20
means success that can be returned by status() when there is a  value=20
stored?
>
>>>> A conversion to bool should help also.
>>> Would true mean that a value is present?  Or that the status
>>> is success?  How would the wrapper know what value success is?
>> That the value is present.
> So, in your approach would the status type have a success value
> or not?
>
>
The status type is independent of the class expected_or_error_code, so I=20
guess it will have a success value

If we want more that one error_code value to mean success, but with=20
specific information (e.g. for a queue that manage congestion, the push=20
operation could succeed with a status congested)  I would use a=20
refinement of pair<T, error_code> and in this case the conversion to=20
bool wold be less useful as the user needs to inspect the status even=20
when there is a stored value T.
Were you thinking to this kind of use cases?

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/?hl=3Den.



.


Author: Lawrence Crowl <crowl@googlers.com>
Date: Thu, 28 Mar 2013 15:30:16 -0700
Raw View
On 3/27/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> Le 28/03/13 02:19, Lawrence Crowl a =E9crit :
> > On 3/27/13, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
> > > What I want is
> > >
> > > T expected_or_error_code<T>::value();
> > >
> > > Return: return the stored value (if one).
> > > Throws: system_error with the stored error_code if there is no value.
> > > Any exception thrown by the T move constructor.
> >
> > I'm okay with that.
>
> Great.
> >
> > I'm trying to say is that I want
> >
> > U expected_or_error_code<U,T>::status() nothrow;
>
> Oh, are you saying that what you need is the value and the status
> (expected_*and*_error_code), or that there is a specific U value
> that means success that can be returned by status() when there
> is a value stored?

Well, for push, there is no value and so you need some status value
that says success.

For pop, the presence of a value is equivalent to a status of
success.

So a conversion to bool seems tricky.

> > So, in your approach would the status type have a success value
> > or not?
>
> The status type is independent of the class expected_or_error_code,
> so I guess it will have a success value
>
> If we want more that one error_code value to mean success, but with
> specific information (e.g. for a queue that manage congestion,
> the push operation could succeed with a status congested) I
> would use a refinement of pair<T, error_code> and in this case
> the conversion to bool wold be less useful as the user needs to
> inspect the status even when there is a stored value T.  Were you
> thinking to this kind of use cases?

Yes, I was.  If we are going to do a general facility, it should
cover more use cases than the queue proposal.

--=20
Lawrence Crowl

--=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/?hl=3Den.



.