[review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
107 messages Options
123456
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
On 05/14/2017 01:44 PM, Niall Douglas via Boost wrote:

> Boost-lite provides the cmake based build, config, test, Boost.Test
> alternative, install, partial preprocess single header include
> generation and much of the internal implemention classes used by
> Outcome. However if accepted then Outcome would gain a Boost.Build
> veneer and be auto generated by script from the standalone Outcome same
> as Boost.ASIO is, and so I figure none of that is in scope for this review.

It is still unclear exactly what code is under review. What does this
potentially auto-generated code that might enter Boost look like?

Is the code in the "attic" folder under review?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 5/14/17 7:56 AM, Niall Douglas via Boost wrote:

> Apparently some years ago they were common enough in submitted new Boost
> libraries, and indeed some internal sublibraries went on to later become
> Boost libraries in their own right.
>
> We should proceed here with the Outcome review the same way as it was
> with those preceding cases. Whatever the precedent is.
>
> (I'm not sure what the exact precedent is, whomever knows for sure
> please speak, but be aware that most of the dependency on boost-lite is
> substitutable for Boost proper)

I can't say I know for sure, but I do have some experience with this.

While creating the serialization library, I depended on existing boost
solutions to the extent possible.  MPL, config, spirit and I'm sure a
bunch of others I don't remember. Someone else later added file_system
and system to the tests. So there is, was and always will be a strong
dependency between the serialization library and the rest of boost.

Still I needed some stuff that didn't exist: extended_type_info,
composable dataflow iterators, BOOST_STRONG_TYPEDEF, singleton,
state_saver, BOOST_STATIC_WARNING.  I created them as "private
libraries" in order to keep the development effort within bounds. It's
much easier to build and maintain a library as the composite of 10
smaller otherwise decoupled components than try to understand things as
a whole.  I also looked forward when some of these "private libraries"
might get promoted to being boost libraries in their own right.  What
actually happened was:

a) I tried to put these in boost namespace as they were not really part
of the serialization library itself.  I caught hell for this from an
important booster who is now no longer involved in boost.  So I moved
them below the serialization namespace.

b) a number of these "private libraries" got adopted for general usage
such that I get bug reports related to usage outside the serialization
library.  These include dataflow iterators, strong typedef, and singleton.

c) a number just didn't work out - BOOST_STATIC_WARNING could never
really be made to work across all platforms.  BOOST_STRONG_TYPEDEF fell
out of use in the serialization library due to evolution in
understanding on my part - but continues to be used.

d) a number got supplanted by real boost libraries - though I didn't
update the serialization library to use them.  Type index is similar to
extended type info.  We now have a component for dealing with unicode
(which hasn't worked for me BTW). We now have boost.ranges which looks
to me to replace dataflow iterators

One key component doesn't fit the above - boost::utf8_codecvt written by
ron garcia many, many years ago.  He must have done a good job as it
seems to be the only reliable implementation of this much needed
facility.  This was one of the components I wanted to add to the boost
root but was prohibited from doing so.  It was shared between several
libraries so it wasn't a good idea to put it under serialization.  But
being in boost detail there was no place for tests - which was pretty
important since may standard libraries had quirky behavior in this area.
While no one was looking, I snuck in a test somewhere which helped but
we're still #including the source into other libraries because
utf8_codecvt was never "officially reviewed".  This will be an ongoing
saga since <codecvt> is now being dropped from the standard for being
unreliable - oh well.

So that short story describes my experience in this area - I don't know
if it explains anything though.  Make of it what you will.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> Furthermore, Outcome is itself already generated by script. When you
>> include Outcome, you are including the pregenerated edition. Therefore
>> generating a "boost flavoured" edition of same is no different.
>>
>> That means both standalone Outcome and any potential Boost.Outcome are
>> exactly the same class of citizen, which is to say first class
>
> Well, not quite. Let's suppose it's accepted. There is a repo under
> boostorg, boostorg/outcome, that hopefully contains headers. Someone
> issues a pull request against one of those headers. To incorporate this
> PR, you need to backport it into the primary Outcome source, then rerun
> the boostification script, then commit the result to the boostorg repo,
> then check whether the changes match the PR.
>
> Correct?

It depends on what conditions the peer review places on Outcome to be
accepted.

If the repo were accepted as is presented - and my hope would be that it
is - then users will be using it directly.

However even if it isn't, the situation with ASIO hasn't been
particularly problematic. Chris figures out an equivalent patch and
applies it to standalone ASIO. It's ok.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> About a year ago when I was considering whether to invest the
>> considerable effort to bring Outcome into a Boost ready form I asked
>> here about internal sublibraries.
>>
>> Apparently some years ago they were common enough in submitted new Boost
>> libraries, and indeed some internal sublibraries went on to later become
>> Boost libraries in their own right.
>>
>> We should proceed here with the Outcome review the same way as it was
>> with those preceding cases. Whatever the precedent is.
>>
>> (I'm not sure what the exact precedent is, whomever knows for sure
>> please speak, but be aware that most of the dependency on boost-lite is
>> substitutable for Boost proper)
>
> I'm not sure I understand what you mean. You're submitting a library
> for review. Everything in the library is subject to review - the
> design, the implementation, the documentation, the tests.
>
> The implementation of Outcome includes something called boost-lite
> right now. Reviewers are allowed to review any files in this
> boost-lite, just as they review any implementation detail of Outcome,
> right?

It's up to the reviewer as to how much to review or not.

Whatever constructive feedback they have, irrespective of whether
Outcome uses that part or not, I'll gladly take it. I would say it may
make Charley's life tough to disambiguate feedback though.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 14/05/2017 16:31, Peter Dimov via Boost wrote:
>> Documentation:
>>   https://ned14.github.io/boost.outcome/index.html
>
> Why does the library make the types possibly-empty? I couldn't find the
> answer in the documentation.

Do you mean empty angle brackets in the make functions? i.e.
outcome::make_exceptional_outcome<>()?

If so, they are superfluous and can be omitted, they were there for
exposition only (see the functions docs and you'll see why). The code
compiles fine without them. If you feel that they ought to be removed
from the code examples in the docs, please do say so during your review,
though as I mention they were deliberately left in to remind people look
up the API docs.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:
> On 14/05/2017 16:31, Peter Dimov via Boost wrote:
> >> Documentation:
> >>   https://ned14.github.io/boost.outcome/index.html
> >
> > Why does the library make the types possibly-empty? I couldn't find the
> > answer in the documentation.
>
> Do you mean empty angle brackets in the make functions? i.e.
> outcome::make_exceptional_outcome<>()?

No, I mean that the types have an empty state. variant<T...> and expected<T,
E> don't have one.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:

> > Well, not quite. Let's suppose it's accepted. There is a repo under
> > boostorg, boostorg/outcome, that hopefully contains headers. Someone
> > issues a pull request against one of those headers. To incorporate this
> > PR, you need to backport it into the primary Outcome source, then rerun
> > the boostification script, then commit the result to the boostorg repo,
> > then check whether the changes match the PR.
> >
> > Correct?
>
> It depends on what conditions the peer review places on Outcome to be
> accepted.
>
> If the repo were accepted as is presented - and my hope would be that it
> is - then users will be using it directly.

This answer makes no sense to me. Boost acceptance implies that the library
is distributed as part of a Boost release. How could users be using it
directly?


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> It is still unclear exactly what code is under review. What does this
> potentially auto-generated code that might enter Boost look like?

The auto generated file is include/boost/outcome/outcome_v1.0.hpp. It is
a single file representing the entire of Outcome, including all
dependencies. It is automatically used by
include/boost/outcome/outcome.hpp if the conditions are right.

> Is the code in the "attic" folder under review?

There is more than one attic folder incidentally.

Stuff in attic can be safely disregarded for this review. Outcome
originally documented how to extend basic_monad with custom semantics by
end users to make new monads, but Hana does all that stuff much better,
so extensibility is no longer advertised.

Niall


--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> > Why does the library make the types possibly-empty? I couldn't find
>> the > answer in the documentation.
>
> No, I mean that the types have an empty state. variant<T...> and
> expected<T, E> don't have one.

C++ 17's variant<...> does actually. It's called valueless by exception.
It is hoped the valueless state may be removed from a future C++
standard, but for now it is present.

outcome<T>, result<T> and option<T> all have formal empty states as part
of their programming model. They are quite useful for a multitude of
uses, I mainly have used them to early out from a sequence of monadic
operations or to signal an abort from a noexcept function.

expected<T, E> does not have an empty state, and as
https://ned14.github.io/boost.outcome/md_doc_md_08-expectedsynopsis.html
explains, that will be fixed soon (end of this week on develop branch I
currently expect). For those interested in tracking the fix, you can
watch https://github.com/ned14/boost.outcome/issues/11.

(In case you are wondering why I submitted Outcome with a "defective"
expected<T, E>, it was because I was not aware of many of the deviations
from LEWG Expected that Outcome's Expected had until after my ACCU talk.
My thanks to Anthony Williams and Vicente for informing me. Realising I
could not fix all the deviations in time for code freeze for this
review, I prioritised and fixed the worst problems first. The never
empty state didn't make it in time, but as I say, it should be fixed on
develop branch within the week and it is not a state which will ever
arise unless you like throwing exceptions from your move and copy
constructors).

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:

> outcome<T>, result<T> and option<T> all have formal empty states as part
> of their programming model. They are quite useful for a multitude of uses,
> I mainly have used them to early out from a sequence of monadic operations
> or to signal an abort from a noexcept function.

Would you mind going into more detail with respect to the use cases?

What does returning an empty result mean to the caller, conceptually? The
idea of these result types is to return either a value or a reason for the
lack of value, and an empty state is lacking both the value and the
explanation for why the value is missing.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> Documentation:
>   https://ned14.github.io/boost.outcome/index.html

"To whomever it was who proposed the name "Outcome" for the library after a
very extended period of name bikeshedding on boost-dev. I had been minded to
call the library "Boost.Donkey" just to shut everyone up because the name
bike shedding was getting ridiculous. But Outcome is a lot nicer, so thank
you to whomever it was."

That would be Paul Bristow, in

https://lists.boost.org/Archives/boost/2015/05/222687.php 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 12/05/2017 04:19, charleyb123 wrote:
> The formal review of Niall Douglas' Outcome library starts next week
> (Fri-19-May to Sun-28-May).
[...]
> - What is your evaluation of the documentation?

During a quick skim through the docs: in "Expected<T, E> in Practice"
section "The tension between type safety and convenient programming",
it's unclear why the final example is any "better" than the ones
preceding it.

In particular, if you're going to explicitly add a constructor to
MathError2 such that it knows how to construct itself from MathError1
(as in the final example), why would you not put the switch statement
from the first example into that constructor, such that it actually
translates the error codes into the expected domain?  Especially when
there is no loss or overlap in doing so, as in these examples?

Granted std::error_code does let you transport "foreign" error codes,
but surely translating recognised codes from a method's internal
implementation to those of its external interface is desirable?  (Though
perhaps that may depend somewhat on your views of encapsulation and
implementation hiding.)



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> outcome<T>, result<T> and option<T> all have formal empty states as
>> part of their programming model. They are quite useful for a multitude
>> of uses, I mainly have used them to early out from a sequence of
>> monadic operations or to signal an abort from a noexcept function.
>
> Would you mind going into more detail with respect to the use cases?

That would be tricky. The empty state is for whatever the programmer
wants it to mean for some use case. It's a bit like returning a null
pointer, that could mean failure, or success, or something else. Totally
up to the programmer.

> What does returning an empty result mean to the caller, conceptually?
> The idea of these result types is to return either a value or a reason
> for the lack of value, and an empty state is lacking both the value and
> the explanation for why the value is missing.

The major refinement of outcome<T>, result<T> and option<T> over
expected<T, E> is that you **never** get undefined behaviour when using
their observers like you do with expected<T, E>. So when you call
.error() for example, you always get well defined semantics and behaviours.

This is intended to let you skip manually writing boilerplate when using
outcome<T>, result<T> and option<T>, and instead rely on the default
behaviours. Let's imagine this:

extern result<Foo> blah() noexcept;
...
result<void> nah()
{
  auto v = blah();
  if(v)
  {
    Do something with v.value() ...
  }
  else
  {
    Do something with v.error() ...
  }
}

So if blah() returns success, we do something with the Foo returned, if
blah() returns failure we do something with the error returned. Those
are the two "normal" execution paths for binary success and failure. But
let's say blah() wanted to abort nah(), it returns an empty result. That
will test as boolean false, and when .error() is called you get a C++
exception thrown of type monad_error(no_state).

  auto v = blah();
  if(v)
  {
    Do something with v.value() ...
  }
  else
  {
    Do something with v.error() ... throws if v is empty
  }

In the above case empty causes a C++ exception throw, which will abort
the caller's execution. You can however use that third state for any
meaning you like. It's the same difference as ternary logic over boolean
logic. If you don't want the empty state to cause a throw and simply be
a third state handled normally:

  auto v = blah();
  if(v.has_value())
  {
    Do something with v.value() ...
  }
  else if(v.has_error())
  {
    Do something with v.error() ...
  }
  else
  {
    result was empty ...
  }

outcome<T>, result<T> and option<T> also have less-expressive to
more-expressive implicit conversion, so if you feed an option<T> to
something consuming an outcome<T>, it'll implicitly upconvert with no
loss of information, including loss of any empty state. In larger code
bases, it's very common to have low level code be using option<T> and
result<T>, and higher level code using outcome<T> or C++ exception
throws. The implicit convertibility without loss of original information
and avoiding needless boilerplate was a major design goal for Outcome,
as well as eliminating all the implicit reinterpret_cast<>'s which are
in std::optional<T> and std::expected<T, E>.

I appreciate that all that was quite hand wavy, and I didn't give a
concrete use case. But I've used in my own code the empty state for
everything from an assert failure through to checking if a search found
something e.g.

outcome<Foo> found;  // default constructs to empty
for(auto &i : container)
{
  auto v = something(i); // returns a result<Foo>
  if(v)  // if not errored
  {
    found = std::move(v);  // auto upconverts
    break;
  }
}
if(!found)
{
  die();
}

It's really hard to be more specific. Do ask if the above doesn't make
sense to you. It's midnight as I type this, I am probably being unclear.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> If you are referring to a cross-platform implementation of
>> __builtin_expect that uses regular C++ then you have my full support,
>> you should propose such a library. As a Visual C++ user I would find
>> that very helpful!

https://groups.google.com/a/isocpp.org/forum/#!searchin/sg14/likely/sg14/jU82E1n2WPE/6py5KioTFAAJ

There's one here. I don't think VCC supports any form of real branch
hinting at present though :)


> There was a very interesting talk at ACCU (unfortunately in the
> non-videoed room) by a HFT guy explaining all the ways in which recent
> GCC versions have bugged __builtin_expect, like inverting the code path
> you specifically told the compiler was the hot path.

That kind of thing certainly matches my experience of using it - there
are situations where my code was 99.9999% hot path, but somehow
utilizing builtin_expect made benchmarks worse, assumably by mucking up
the optimization code.


> But I can see a feature like __builtin_expect that going the way of the
> dodo as the compiler vendors really would prefer if you used profile
> guided optimisation instead. Passing that sort of micro-info from the
> parser to the backend is surely complex to get right.

Unfortunately that would not be kosher for fields like AAA gamedev,
where you're talking massive codebases compiling into singular files
where PGO is not acceptable because user behaviour is not predictable.
And, in my experience, PGO success varieis wildly from compiler to
compiler (VCC2013's was a pessimisation feature - even with simple,
repeatable benchmark code).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> During a quick skim through the docs: in "Expected<T, E> in Practice"
> section "The tension between type safety and convenient programming",
> it's unclear why the final example is any "better" than the ones
> preceding it.

I had thought the text pretty clear that it isn't better per se, but
rather a fusion of the approaches where the type of E is used to prevent
code from returning an invalid-for-that-domain error. Some would (and
indeed have) call it a worst of both worlds, but it does balance a
reasonable amount of getting the compiler to enforce incommensurate
error code domains at compile time, with all error codes being
subclasses of std::error_code, and thus one can strip the type safety in
code further up the call stack such that all error domains feed into a
common error_code based error handling system.

> In particular, if you're going to explicitly add a constructor to
> MathError2 such that it knows how to construct itself from MathError1
> (as in the final example), why would you not put the switch statement
> from the first example into that constructor, such that it actually
> translates the error codes into the expected domain?  Especially when
> there is no loss or overlap in doing so, as in these examples?

If you're writing a switch statement or doing any form of mapping with
error codes, you're doing it wrong from C++ 11 onwards.

One always wants to preserve and propagate exactly the original error
code, unmodified in any way. That's the whole point of <system_error>.

> Granted std::error_code does let you transport "foreign" error codes,
> but surely translating recognised codes from a method's internal
> implementation to those of its external interface is desirable?  (Though
> perhaps that may depend somewhat on your views of encapsulation and
> implementation hiding.)

<system_error> lets code with no knowledge of some custom error code
domain work with that error code domain, and without recompilation. It's
very clever. Both Outcome and Expected are intended to make using
error_code much easier and safer for end users than it has been until now.

Indeed I believe that Charley Bay is giving a talk at C++ Now right now
on exactly the topic of why we all need to be using more <system_error>.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 14/05/2017 23:09, Peter Dimov via Boost wrote:
> That would be Paul Bristow, in
>
> https://lists.boost.org/Archives/boost/2015/05/222687.php

That's an amazing find Peter. I had tried and given up. Thank you.

Logged to https://github.com/ned14/boost.outcome/issues/17.

And thanks to Paul as well.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, May 14, 2017 at 4:33 PM, Niall Douglas via Boost
<[hidden email]> wrote:
> Indeed I believe that Charley Bay is giving a talk at C++ Now right now
> on exactly the topic of why we all need to be using more <system_error>.

Head check: Is the following function signature "correct" or should it
use system_error?

    template<
        typename SyncReadStream,
        typename MutableBufferSequence>
    std::size_t
    read(
        SyncReadStream& s,
        MutableBufferSequence const& buffers,
        boost::system::error_code& ec);

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:

> The major refinement of outcome<T>, result<T> and option<T> over
> expected<T, E> is that you **never** get undefined behaviour when using
> their observers like you do with expected<T, E>. So when you call .error()
> for example, you always get well defined semantics and behaviours.

I fully agree with this design decision of yours, by the way. In fact I
consider that a defect in expected<>.

> you get a C++ exception thrown of type monad_error(no_state).

As a side note, it would be nice from my point of view if you eradicate
these last remaining references to 'monad' in the public interface and make
that outcome_error (resp. outcome_errc, outcome_category.)

> outcome<Foo> found;  // default constructs to empty
> for(auto &i : container)
> {
>   auto v = something(i); // returns a result<Foo>
>   if(v)  // if not errored
>   {
>     found = std::move(v);  // auto upconverts
>     break;
>   }
> }
> if(!found)
> {
>   die();
> }

OK, let's go with that. Why not construct 'found' initially to contain some
error, instead of being empty? You can even define a special errc constant
to denote an empty outcome.

Sure, this will not throw the exception in your earlier example which
accessed v.error() when !v, but is the exception really necessary there?

What I'm driving at is that these result types are conceptually (T|E) and
the empty state could just be a special case of E.

Or, in more general terms, I feel that there's still much extra weight that
can be stripped off (not in terms of sizeof, but in terms of the interface.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/05/2017 11:33, Niall Douglas via Boost wrote:

>> In particular, if you're going to explicitly add a constructor to
>> MathError2 such that it knows how to construct itself from MathError1
>> (as in the final example), why would you not put the switch statement
>> from the first example into that constructor, such that it actually
>> translates the error codes into the expected domain?  Especially when
>> there is no loss or overlap in doing so, as in these examples?
>
> If you're writing a switch statement or doing any form of mapping with
> error codes, you're doing it wrong from C++ 11 onwards.
>
> One always wants to preserve and propagate exactly the original error
> code, unmodified in any way. That's the whole point of <system_error>.

If you have a class which could have any of a large number of possible
implementations (perhaps platform-specific), and as a consumer of that
class you don't care which, why would you want it to expose a
file_not_found error or a database_key_missing error when as far as
you're concerned they're just a key_not_in_dictionary.

Don't take that example too literally -- the point is that if the
internal implementation is hidden, exposing internal errors seems
somewhat meaningless to consumer code.  And brittle -- maybe the
application code was written to handle the file_not_found case but then
the library was changed to use a database backend and started raising
database_key_missing errors instead, and now suddenly all the error
handling is wrong.

Granted the below possibly provides some insulation from that, but it
still requires someone to define a POSIX equivalence, and I'm sure there
would be cases where the same internal error code logically means
different things at the surface API, so such equivalence would be
misleading.

> <system_error> lets code with no knowledge of some custom error code
> domain work with that error code domain, and without recompilation. It's
> very clever. Both Outcome and Expected are intended to make using
> error_code much easier and safer for end users than it has been until now.

Only where someone provides a mapping to standard POSIX errors, or just
wants to log errors without logic.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>
> spaketh Vinnie:
>
<snip>,

Head check: Is the following function signature "correct" or should it

> use system_error?
>
>     template<
>         typename SyncReadStream,
>         typename MutableBufferSequence>
>     std::size_t
>     read(
>         SyncReadStream& s,
>         MutableBufferSequence const& buffers,
>         boost::system::error_code& ec);
>

That signature is "correct":

(a) It happens to use 'boost::system::error_code', which is a complete
C++03 implementation compatible with C++11's <system_error>.

(b) C++11 libraries can consider moving to 'std::error_code'.  Otherwise,
an "adapter" can be implemented to enable 'boost::system::error_code' to
inter-operate with C++11's 'std::error_code'. A nice blog article by Bjorn
Reese on that topic can be found at:
http://breese.github.io/2016/06/18/unifying-error-codes.html

(c) The C++11 'class std::system_error : public std::runtime_error { ...};'
is a convenience utility to 'throw' a 'std::error_code' value as
"payload".  Since your 'read()' function signature (by convention) appears
to be non-throwing, you wouldn't need 'std::system_error' here (as the
'std::error_code' can be populated directly in the function body).

Hope that helps ...?

--charley

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123456
Loading...