[review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
130 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

[review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
Hi, Everyone,

The formal review of Niall Douglas' Outcome (v2) library begins Fri-19-Jan
and continues until Sun-28-Jan, 2018.

Your participation is encouraged, as the proposed library is uncoupled and
focused, and reviewers do not need to be domain experts to appreciate the
potential usefulness of the library and to propose improvements.  Everyone
needs (and has suffered) error handling, and can compose an opinion on that
topic.

Outcome is a header-only C++14 library providing expressive and very
lightweight 'outcome<T>' and 'result<T>' error handling, suitable for
low-latency code bases. The library further provides mechanisms for
wrapping '<success|error|exception>' state to safely wrap throwing APIs;
and poses an idiom of, "islands of exception in a sea of noexcept".

Key features:

*- Makes using 'std::error_code' from C++11's <system_error> more
convenient and safe
*- Good focus on low-latency (with tests and benchmarks)
*- Error-handling algorithmic composition with-or-without C++ exceptions
enabled
*- Dependency only on Boost

Recall a previous Outcome (v1) Boost Review occurred 19-May to 02-June 2017:
  *- Outcome (v1) Review Report:
    *- https://lists.boost.org/Archives/boost/2017/06/235783.php

This review for Outcome (v2) includes significant changes as a result of
feedback from the Outcome (v1) review.  For a list of changes (v1==>v2),
see:
  *- https://github.com/ned14/outcome#changes-since-v1

Reference API docs:
  *- https://ned14.github.io/outcome/reference/

GitHub:
  *- https://github.com/ned14/boost-outcome

Tarball:
  *- https://github.com/ned14/boost-outcome/releases/tag/v2.
0-boost-peer-review

Online "play-pen" (try it out!):
  *- https://wandbox.org/permlink/Ji1khzyxoAR0LJQC

YOUR REVIEW
---------------------
Please post your comments and review to the boost mailing list
(preferably), or privately to the Review Manager (to me ;-). Here are some
questions you might want to answer in your review:

- What is your evaluation of the design?

- What is your evaluation of the implementation?

- What is your evaluation of the documentation?

- What is your evaluation of the potential usefulness of the library?

- Did you try to use the library? With what compiler? Did you have any
problems?

- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

- Are you knowledgeable about the problem domain?

And most importantly:

- Do you think the library should be accepted as a Boost library?

For more information about Boost Formal Review Process, see:
http://www.boost.org/community/reviews.html

Thank you very much for your time and efforts.

--charley
Outcome (v2) Review Manager

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
> The formal review of Niall Douglas' Outcome (v2) library begins Fri-19-Jan
> and continues until Sun-28-Jan, 2018.

I'd just like to take this opportunity to thank all the people who
responded to my call two weeks ago to help comb through the reference
API docs looking for problems and reporting them. I know that we did not
fix all of the problems in time, but what you see before you now is
enormously better than they were just two weeks ago. That's thanks to
you, so thank you.

I'd like to thank Jens Weller for specially expediting the mastering of
the Meeting C++ video so it could appear in the Outcome docs in time for
this review.

And definitely the star of the past two weeks has been Jonathan Müller
who has expended many, many hours adding features and fixing bugs in
Standardese to create the reference API docs you see, despite a heavy
class workload and often really terrible low quality bug reports by me
submitted usually when he was just about to go to bed. Thank you Jonathan!

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
|

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
AMDG

On 01/18/2018 03:07 PM, charleyb123 . via Boost wrote:
>
> Tarball:
>   *- https://github.com/ned14/boost-outcome/releases/tag/v2.
> 0-boost-peer-review
>

  If you're going to provide this, it should contain
documentation that I can read locally.

In Christ,
Steven Watanabe

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
>> Tarball:
>>   *- https://github.com/ned14/boost-outcome/releases/tag/v2.
>> 0-boost-peer-review
>>
>
>   If you're going to provide this, it should contain
> documentation that I can read locally.

The particular theme I chose requires a real web server, it doesn't work
from a file:// address. Hence no point in bundling documentation that
you can read locally in the tarball.

If you would like to read the documentation locally, here's how:

1. Download a prebuilt Hugo binary for your system from
https://github.com/gohugoio/hugo/releases

2. Fetch the standalone tarball from
https://dedi4.nedprod.com/static/files/outcome-v2.0-source-latest.tar.xz
and unpack it.

3. Unpack the Hugo binary into outcome/doc/src

4. In a terminal, cd to outcome/doc/src

5. Run 'hugo serve' and follow the instructions it prints with regard to
a http site on localhost.

If you run into any problems, let me know.

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
|

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
AMDG

On 01/23/2018 02:58 PM, Niall Douglas via Boost wrote:

>>> Tarball:
>>>   *- https://github.com/ned14/boost-outcome/releases/tag/v2.
>>> 0-boost-peer-review
>>>
>>
>>   If you're going to provide this, it should contain
>> documentation that I can read locally.
>
> The particular theme I chose requires a real web server, it doesn't work
> from a file:// address. Hence no point in bundling documentation that
> you can read locally in the tarball.
>

  Frankly, I find this completely ridiculous.
It's also goes against Boost's documentation
guidelines:

http://www.boost.org/development/requirements.html#Documentation

  "The format for documentation should be HTML, and
should not require an advanced browser or
server-side extensions"

> If you would like to read the documentation locally, here's how:
>
> 1. Download a prebuilt Hugo binary for your system from
> https://github.com/gohugoio/hugo/releases
>
> 2. Fetch the standalone tarball from
> https://dedi4.nedprod.com/static/files/outcome-v2.0-source-latest.tar.xz
> and unpack it.
>
> 3. Unpack the Hugo binary into outcome/doc/src
>
> 4. In a terminal, cd to outcome/doc/src
>
> 5. Run 'hugo serve' and follow the instructions it prints with regard to
> a http site on localhost.
>
> If you run into any problems, let me know.
>

In Christ,
Steven Watanabe

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
>> The particular theme I chose requires a real web server, it doesn't work
>> from a file:// address. Hence no point in bundling documentation that
>> you can read locally in the tarball.
>
>   Frankly, I find this completely ridiculous.
> It's also goes against Boost's documentation
> guidelines:
>
> http://www.boost.org/development/requirements.html#Documentation
>
>   "The format for documentation should be HTML, and
> should not require an advanced browser or
> server-side extensions"

1. No server side extensions are needed. It's a static website.

2. Standard HTML5 is generated throughout. It (very slightly) fails
validation currently due to using <center>, but I'll be upgrading to the
latest release of the theme after the review which should fix that.

It ticks all the mandatory boxes in the requirements you link to.

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
|

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
AMDG

On 01/23/2018 03:22 PM, Niall Douglas via Boost wrote:

>>> The particular theme I chose requires a real web server, it doesn't work
>>> from a file:// address. Hence no point in bundling documentation that
>>> you can read locally in the tarball.
>>
>>   Frankly, I find this completely ridiculous.
>> It's also goes against Boost's documentation
>> guidelines:
>>
>> http://www.boost.org/development/requirements.html#Documentation
>>
>>   "The format for documentation should be HTML, and
>> should not require an advanced browser or
>> server-side extensions"
>
> 1. No server side extensions are needed. It's a static website.
>

So, why exactly can't you generate static html?

> 2. Standard HTML5 is generated throughout. It (very slightly) fails
> validation currently due to using <center>, but I'll be upgrading to the
> latest release of the theme after the review which should fix that.
>
> It ticks all the mandatory boxes in the requirements you link to.
>

In Christ,
Steven Watanabe

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
>> 1. No server side extensions are needed. It's a static website.
>>
>
> So, why exactly can't you generate static html?

Most web browsers don't render modern static websites with AJAX,
accessibility, mobile rendering, semantic search etc from file:// for
security reasons. The problem is in the web browser, not in the site.

If you're super adverse to running Hugo, the Python 2 program below will
serve a static website onto localhost for you. Taken from
https://docs.python.org/2/library/simplehttpserver.html:

```
import SimpleHTTPServer
import SocketServer

PORT = 8000

Handler = SimpleHTTPServer.SimpleHTTPRequestHandler

httpd = SocketServer.TCPServer(("", PORT), Handler)

print "serving at port", PORT
httpd.serve_forever()
```

Start using:

python -m SimpleHTTPServer 8000

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
|

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
Niall Douglas wrote:

> Most web browsers don't render modern static websites with AJAX,
> accessibility, mobile rendering, semantic search etc from file:// for
> security reasons. The problem is in the web browser, not in the site.

You could generate the static html using an appropriate offline theme. If
accepted you'll in any event need either static html in doc/html, or a
doc/Jamfile that builds said doc/html. Might as well do that now to give the
reviewers an offline doc.


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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
On 23 January 2018 at 23:10, Peter Dimov via Boost
<[hidden email]> wrote:

> Niall Douglas wrote:
>
>> Most web browsers don't render modern static websites with AJAX,
>> accessibility, mobile rendering, semantic search etc from file:// for
>> security reasons. The problem is in the web browser, not in the site.
>
>
> You could generate the static html using an appropriate offline theme. If
> accepted you'll in any event need either static html in doc/html, or a
> doc/Jamfile that builds said doc/html. Might as well do that now to give the
> reviewers an offline doc.

Using ugly urls and rewriting relative urls would be a good start:

https://gohugo.io/content-management/urls/

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Jan 23, 2018 at 11:55 PM, Niall Douglas via Boost
<[hidden email]> wrote:

>>> 1. No server side extensions are needed. It's a static website.
>>>
>>
>> So, why exactly can't you generate static html?
>
> Most web browsers don't render modern static websites with AJAX,
> accessibility, mobile rendering, semantic search etc from file:// for
> security reasons. The problem is in the web browser, not in the site.
>
> If you're super adverse to running Hugo, the Python 2 program below will
> serve a static website onto localhost for you. Taken from
> https://docs.python.org/2/library/simplehttpserver.html:
>
> ```
> import SimpleHTTPServer
> import SocketServer
>
> PORT = 8000
>
> Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
>
> httpd = SocketServer.TCPServer(("", PORT), Handler)
>
> print "serving at port", PORT
> httpd.serve_forever()
> ```
>
> Start using:
>
> python -m SimpleHTTPServer 8000
>

The file above is not needed (that is an example of usage of the
module) -- just the command line you wrote is enough:

  python -m SimpleHTTPServer 8000

Or for Python 3, even better, binding only to localhost:

  python -m http.server 8000 --bind 127.0.0.1

Not that I agree with something like the Boost docs requiring a
server, but it is even easier to set up one :)

My 2 cents,
Miguel

> 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

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> Most web browsers don't render modern static websites with AJAX,
>> accessibility, mobile rendering, semantic search etc from file:// for
>> security reasons. The problem is in the web browser, not in the site.
>
> You could generate the static html using an appropriate offline theme.
> If accepted you'll in any event need either static html in doc/html, or
> a doc/Jamfile that builds said doc/html. Might as well do that now to
> give the reviewers an offline doc.

Here is an offline archive of the docs website as pulled and converted
by HTTrack:

https://github.com/ned14/outcome/releases/download/v2.0-boost-peer-review/outcome_html_docs_offline.zip

I had a quick flick through and it seems mostly the same. Search doesn't
work obviously. I would emphasise that the review submission is the
public website at https://ned14.github.io/outcome/, and not this zip
archive which hasn't received anything like the same amount of
validation and checking.


Regarding what else you said, yes one could simply run Hugo and tell it
to make an offline copy. After all the true source content is written in
Markdown, and actually any Markdown to HTML/PDF/DocBook processor will
technically do.

However the documentation took as long to do as everything else put
together (writing, testing, everything else). Some four months of effort
- and not just by me either - went into the docs alone. The public
website https://ned14.github.io/outcome/ has many problems and issues,
but at least I know what those are, and I am prepared for any review
feedback on those.

Quickly firing out an offline website, getting it properly validated and
throwing it into a ZIP file is not doable in the time available to me
before the review ends. I only get, at most, two free hours per day and
those go on writing emails like this one.


Regarding how these docs would end up in Boost if the library is
accepted, historically Boost has preferred to generate the docs from
their original sources rather than take a copy of the HTML dumped out. I
would assume this would continue to be the case, and so we'd need some
theme which outputs something with the Boost look and feel, and fix up
the Boost servers with Hugo et al and get them into a Jamfile as you say.

But those involve decisions by those who maintain the Boost website, and
many more weeks of tweaking things in whatever direction is chosen
ultimately. As I do not know what that decision would be until after
this review, I have kicked that can down the road for now. For all I
know, maybe they would prefer a static HTML dump, but I suspect not.

You're right Peter that all this is easy, but it is also time consuming
and detail orientated. And that means weeks of time must elapse as I am
currently on contract.

Also, nobody seems yet to have noticed the many problems in the
Standardese generated output. There is a fair bit of rope to pull in on
that yet too, Jonathan I am sure awaits feedback from this review with
anticipation.

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
|

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Jan 18, 2018 at 2:07 PM, charleyb123 . via Boost <
[hidden email]> wrote:

> Hi, Everyone,
>
> The formal review of Niall Douglas' Outcome (v2) library begins Fri-19-Jan
> and continues until Sun-28-Jan, 2018.
>

From the Outcome documentation:

auto read_int_from_file(string_view path) noexcept
  -> outcome::result<int>
{
  OUTCOME_TRY(handle, open_file(path));    // decltype(handle) == Handle
  OUTCOME_TRY(buffer, read_data(handle));  // decltype(buffer) == Buffer
  OUTCOME_TRY(val, parse(buffer));         // decltype(val) == int
  return val;
}

Question: if using the OUTCOME_TRY macro is equivalent to calling the
function, checking for error and then returning an error if there is an
error, how is this different from using exceptions? Semantically, exception
handling does nothing more than check for errors and returning errors if
there were errors, with much more readable syntax:

return parse(read_data(open_file(path)));

This kind of macro use seems rather inelegant and more appropriate for C
programs, though it may be justified in C since it lacks exception handling.

Emil

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
> Question: if using the OUTCOME_TRY macro is equivalent to calling the
> function, checking for error and then returning an error if there is an
> error, how is this different from using exceptions? Semantically, exception
> handling does nothing more than check for errors and returning errors if
> there were errors, with much more readable syntax:

Semantically they are similar, and if the compiler implements EH using
SJLJ or any of the non-table approaches, they are also pretty much
identical in terms of implementation.

But on table-based EH, the cost of handling failure is many orders of
magnitude more expensive than handling success. OUTCOME_TRY emulates the
SJLJ balance of success/failure, you pay a constant fixed overhead
during successful codepaths in exchange for predictable overhead during
unsuccessful codepaths. So OUTCOME_TRY opts back into non-table EH
characteristics on table-based EH implementations.

Hence the "Decision Matrix" at
https://ned14.github.io/outcome/use-matrix/. There is no point in using
Outcome if failure almost never occurs. Use exceptions instead. But if
failure occurs in say 0.1% of the time, Outcome likely will win,
possibly even in 0.01% of the time depending. See
https://ned14.github.io/outcome/faq/#what-kind-of-performance-benefits-will-using-outcome-in-my-code-bring

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
|

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
2018-01-27 0:31 GMT-03:00 Emil Dotchevski via Boost <[hidden email]>:

> Question: if using the OUTCOME_TRY macro is equivalent to calling the
> function, checking for error and then returning an error if there is an
> error, how is this different from using exceptions? Semantically, exception
> handling does nothing more than check for errors and returning errors if
> there were errors


There is a single control flow to analyse: the return of the function. You
don't need a "parallel" control flow construct to check for error case.

This simplification just adds up:


   - You can't forget to check the error case (it's part of the type
   system).
   - It's self-documenting.
   - There are no strange interactions between Outcome and the rest of the
   language (e.g. throwing destructors, transporting exception between
   threads, and so on...).
   - Add templates to the mix and you'll remember who is responsible for
   non-insignificant amount of rules and added code boilerplate.
   - ...


OUTCOME_TRY is just convenience. It mirrors the Rust's try macro:
https://doc.rust-lang.org/1.9.0/std/macro.try!.html

Rust has sum types and pattern matching at language level from day 0 (day 0
is Rust 1.0). The rest of the features were thought (or revised) with
pattern matching in mind before 1.0 release. It has conveniences that C++
will never have (Rust /lacks/ constructors that can throw, moves that can
throw and moved objects that will call a destructor). Rust doesn't have
exceptions and nobody misses them.

On the level of what C++ could have, Rust has monadic operations.

with much more readable syntax:
>
> return parse(read_data(open_file(path)));


Check OUTCOME_TRYX

Of course it'd be more verbose:

return parse(OUTCOME_TRYX(read_data(OUTCOME_TRYX(open_file(path)))));

To the point of being ridiculous. Here it'd be better to split it in one
line per call.

In Rust, try! macro is only 4 letters long. Also, it was "promoted" to an
operator: https://m4rw3r.github.io/rust-questionmark-operator

With monadic operations, we could turn the above code into something like:

return open_file(path).and_then(read_data).and_then(parse);

But this assumes all operations return the same error type (e.g.
std::error_code). This should be true at least to the I/O functions
(open_file and read_data). Maybe we could use something like
std::common_type or another magic detection to relax the requirements (i.e.
it must be the same error type) a bit (it'd diverge from other
implementations, but we have this freedom).

--
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jan 26, 2018 at 7:57 PM, Niall Douglas via Boost <
[hidden email]> wrote:

> > Question: if using the OUTCOME_TRY macro is equivalent to calling the
> > function, checking for error and then returning an error if there is an
> > error, how is this different from using exceptions? Semantically,
> exception
> > handling does nothing more than check for errors and returning errors if
> > there were errors, with much more readable syntax:
>
> Semantically they are similar, and if the compiler implements EH using
> SJLJ or any of the non-table approaches, they are also pretty much
> identical in terms of implementation.
>

I was only talking about semantics. Are you saying that, except for
performance considerations, there is no reason to use

OUTCOME_TRY(handle, open_file(path));
OUTCOME_TRY(buffer, read_data(handle));
OUTCOME_TRY(val, parse(buffer));
return val;

instead of

return parse(read_data(open_file(path)));

Emil

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
> I was only talking about semantics. Are you saying that, except for
> performance considerations, there is no reason to use
>
> OUTCOME_TRY(handle, open_file(path));
> OUTCOME_TRY(buffer, read_data(handle));
> OUTCOME_TRY(val, parse(buffer));
> return val;
>
> instead of
>
> return parse(read_data(open_file(path)));

It is rare that functions would consume an Outcome as a parameter. After
all Outcome is not Expected, and Default Actions get a throw site away
from the cause of the error.

But in the end, there is nothing stopping you using Outcome as if
Expected, and there is a `checked<T, E>` typedef in there just for those
wanting a logic error checking Monad like Expected.

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
|

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Jan 27, 2018 at 5:33 AM, Vinícius dos Santos Oliveira <
[hidden email]> wrote:

> 2018-01-27 0:31 GMT-03:00 Emil Dotchevski via Boost <[hidden email]
> >:
>
>> Question: if using the OUTCOME_TRY macro is equivalent to calling the
>> function, checking for error and then returning an error if there is an
>> error, how is this different from using exceptions? Semantically,
>> exception
>> handling does nothing more than check for errors and returning errors if
>> there were errors
>
>
> There is a single control flow to analyse: the return of the function. You
> don't need a "parallel" control flow construct to check for error case.
>

Where is the parallel control flow in return parse(read_data(open_file()))?

>
>    - You can't forget to check the error case (it's part of the type
>    system).
>
> You can't forget to check for errors if you use exceptions, either.
Literally, if you use exceptions it is as if the compiler writes the ifs
for you.

>
>    - It's self-documenting.
>
> Only to the extent that you can see that a function may return an error.
With exceptions, except for noexcept functions, functions may "return" an
error.

Some would count the fact that with e.g. Outcome you can specify what kind
of errors can be returned as an advantage, but that is similar to
statically enforced exception specifications. Sutter explained why that is
a bad idea back in 2007: https://herbsutter.com/2007/01/24/questions-about-
exception-specifications/.

>
>    - There are no strange interactions between Outcome and the rest of
>    the language (e.g. throwing destructors, transporting exception between
>    threads, and so on...).
>
> So, don't throw in destructors. Also, you can't use Outcome in
destructors, but that is fine -- it is a logic error to not be able to
destroy an object.

Though this reminds me: in C++, exceptions are the only way constructors
may report an error, and this is very deliberate, integral part of RAII.
This guarantees that you can't use an object that failed to initialize,
which is the reason why member functions are free to assume, rather than
check, that all invariants of the class have been established.

Thus, exception handling is an integral part of the C++ object
encapsulation model. Choose to not use exceptions and the result is that
like in C, each function must check whether the object was initialized, and
return some error code to indicate that condition. You're replacing a
bullet-proof automatically enforced error checking system with a manual
one, prone to errors; worse, we're talking about error handling code, which
by its very nature is difficult to test.

OUTCOME_TRY is just convenience. It mirrors the Rust's try macro:
> https://doc.rust-lang.org/1.9.0/std/macro.try!.html
>

There are many languages which lack C++ exception handling, it doesn't mean
that their approach is better. It is common for programmers coming from a
different background, forced by reality to have to use C++, to complain
what a horrible language it is for lacking this or that feature. :)


> With monadic operations, we could turn the above code into something like:
>
> return open_file(path).and_then(read_data).and_then(parse);
>

> But this assumes all operations return the same error type (e.g.
> std::error_code).
>

I'd much rather use return parse(read_data(open_file())) without having to
assume anything.
Emil

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Jan 27, 2018 at 4:13 PM, Niall Douglas via Boost <
[hidden email]> wrote:

> > I was only talking about semantics. Are you saying that, except for
> > performance considerations, there is no reason to use
> >
> > OUTCOME_TRY(handle, open_file(path));
> > OUTCOME_TRY(buffer, read_data(handle));
> > OUTCOME_TRY(val, parse(buffer));
> > return val;
> >
> > instead of
> >
> > return parse(read_data(open_file(path)));
>
> It is rare that functions would consume an Outcome as a parameter. After
> all Outcome is not Expected, and Default Actions get a throw site away
> from the cause of the error.
>

My question is really what is the use case for OUTCOME_TRY. I'm asking
because the above use of OUTCOME_TRY is literally the first example given
in the Outcome documentation, yet the code would be simpler, more readable,
more robust and, it seems to me, semantically very similar if it used
exceptions instead. So the question is what's the upside of using the
cumbersome macro rather than relying on exception handling? Is it just the
perceived performance improvement?

Emil

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

Re: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Boost - Dev mailing list
> So the question is what's the upside of using the
> cumbersome macro rather than relying on exception handling? Is it just the
> perceived performance improvement?

Outcome's default configuration is to do nothing when E is a UDT. If E
matches the various documented traits, observing T when an E is present
will throw various exceptions according to the rules you tell it. The
TRY operation is therefore an alternative way of unwinding the stack
than throwing exceptions, one which does not invoke EH table scans.

Sure, it's more manual and cumbersome, but it also means that the
failure handling path has the same latency as the success handling path.
And yes, if your EH implementation in the compiler is not table based,
then there is not much performance gain.

Some on WG21 have mused about an attribute by which one could mark up a
function, class or namespace to say "please use balanced EH here". It
would not be an ABI break, and code with the different EH mechanisms
could intermix freely. If Outcome is successful in terms of low latency
userbase, I don't doubt that SG14 will propose just such an EH attribute
in the future.

Until then, this is a library based solution.

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