Quantcast

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

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

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

Boost - Dev mailing list
Hi Everyone,

** HEADS UP, NEXT WEEK **

The formal review of Niall Douglas' Outcome library starts next week
(Fri-19-May to Sun-28-May).

Your participation is encouraged, as the proposed library is uncoupled and
focused, and reviewers don't 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 type-safe
ultra-lightweight error handling, suitable for low-latency code bases.

Key features:

*- Makes using std::error_code from C++11's <system_error> more convenient
and safe
*- Provides high-quality implementation of proposed std::expected<T,E> (on
C++20 standards track)
*- Good focus on low-latency (with tests and benchmarks)
*- Error-handling algorithmic composition with-or-without C++ exceptions
enabled
*- No dependencies (not even on Boost)

This review is timely, as C++17 brings us std::optional<T>.  The upcoming
std::expected<T,E> (an implementation provided in Outcome) is a
generalization of std::optional<T> that provides a <success|fail> value,
where the unhappy result is a 'std::error_code' or an instance of
"your-chosen-error-type".

The library further provides 'outcome<T,error-code,exception-ptr>' for
handling <success|error|exception> to safely wrap throwing APIs.

Documentation:
  https://ned14.github.io/boost.outcome/index.html

ACCU 2017 talk including design rationale:
  https://www.youtube.com/watch?v=XVofgKH-uu4

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

Latest tarball:
  https://github.com/ned14/boost.outcome/releases/
download/boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz

Note:  Tarball might be easiest; but if you want to clone from GitHub
directly, after the clone you should run the following command to get the
source zip exactly:  git submodule update --init --recursive

NEXT WEEK (when the public review is started):  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

_______________________________________________
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
How does expected work in a world of multiple return value, structured bindings?

________________________________
From: Boost <[hidden email]> on behalf of charleyb123 . via Boost <[hidden email]>
Sent: Thursday, May 11, 2017 12:19:03 PM
To: [hidden email]
Cc: charleyb123 .
Subject: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Hi Everyone,

** HEADS UP, NEXT WEEK **

The formal review of Niall Douglas' Outcome library starts next week
(Fri-19-May to Sun-28-May).

Your participation is encouraged, as the proposed library is uncoupled and
focused, and reviewers don't 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 type-safe
ultra-lightweight error handling, suitable for low-latency code bases.

Key features:

*- Makes using std::error_code from C++11's <system_error> more convenient
and safe
*- Provides high-quality implementation of proposed std::expected<T,E> (on
C++20 standards track)
*- Good focus on low-latency (with tests and benchmarks)
*- Error-handling algorithmic composition with-or-without C++ exceptions
enabled
*- No dependencies (not even on Boost)

This review is timely, as C++17 brings us std::optional<T>.  The upcoming
std::expected<T,E> (an implementation provided in Outcome) is a
generalization of std::optional<T> that provides a <success|fail> value,
where the unhappy result is a 'std::error_code' or an instance of
"your-chosen-error-type".

The library further provides 'outcome<T,error-code,exception-ptr>' for
handling <success|error|exception> to safely wrap throwing APIs.

Documentation:
  https://ned14.github.io/boost.outcome/index.html

ACCU 2017 talk including design rationale:
  https://www.youtube.com/watch?v=XVofgKH-uu4

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

Latest tarball:
  https://github.com/ned14/boost.outcome/releases/
download/boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz

Note:  Tarball might be easiest; but if you want to clone from GitHub
directly, after the clone you should run the following command to get the
source zip exactly:  git submodule update --init --recursive

NEXT WEEK (when the public review is started):  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

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

PRIVILEGED AND CONFIDENTIAL

This communication and any accompanying documents are confidential and privileged. They are intended for the sole use of the addressee. If you receive this transmission in error, you are advised that any disclosure, copying, distribution, or the taking of any action in reliance upon this communication is strictly prohibited. If you have received this communication in error, please contact me at the above email address and destroy all copies of the original message. Thank you.

_______________________________________________
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
On 12/05/2017 14:13, Jarrad Waterloo via Boost wrote:
> How does expected work in a world of multiple return value, structured bindings?

I see no reason that they shouldn't work perfectly. Expected provides
lvalue, const lvalue, rvalue and const rvalue observers. So it should
just work.

But I'll admit I haven't tested it. Can you suggest a use case which you
would like to know if it works with Expected? I can throw together some
code and see if it works for you.

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
2017-05-12 18:26 GMT+02:00 Niall Douglas via Boost <[hidden email]>:

> On 12/05/2017 14:13, Jarrad Waterloo via Boost wrote:
> > How does expected work in a world of multiple return value, structured
> bindings?
>
> I see no reason that they shouldn't work perfectly. Expected provides
> lvalue, const lvalue, rvalue and const rvalue observers. So it should
> just work.
>
> But I'll admit I haven't tested it. Can you suggest a use case which you
> would like to know if it works with Expected? I can throw together some
> code and see if it works for you.
>

Or maybe what Jarrad was asking was wether one could write code like this:

```
outcome<int> fun();

int main()
{
  auto [val, err] = fun();
  if (err) ...
}
```

But if this was the question: outcome cannot be used in this way. For the
same reason as variant<> cannot be used here: because outcome<> can store
only one of - value or error code - at a time: never both.

Regards,
&zej;

_______________________________________________
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
Sounds useful.
I welcome a 'expected' implementation, even if, in my testing, results
from this sort of thing are highly CPU-dependent and non-intuitive.


On 12/05/2017 4:19 a.m., charleyb123 . via Boost wrote:

> Hi Everyone,
>
> ** HEADS UP, NEXT WEEK **
>
> The formal review of Niall Douglas' Outcome library starts next week
> (Fri-19-May to Sun-28-May).
>
> Your participation is encouraged, as the proposed library is uncoupled and
> focused, and reviewers don't 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 type-safe
> ultra-lightweight error handling, suitable for low-latency code bases.
>
> Key features:
>
> *- Makes using std::error_code from C++11's <system_error> more convenient
> and safe
> *- Provides high-quality implementation of proposed std::expected<T,E> (on
> C++20 standards track)
> *- Good focus on low-latency (with tests and benchmarks)
> *- Error-handling algorithmic composition with-or-without C++ exceptions
> enabled
> *- No dependencies (not even on Boost)
>
> This review is timely, as C++17 brings us std::optional<T>.  The upcoming
> std::expected<T,E> (an implementation provided in Outcome) is a
> generalization of std::optional<T> that provides a <success|fail> value,
> where the unhappy result is a 'std::error_code' or an instance of
> "your-chosen-error-type".
>
> The library further provides 'outcome<T,error-code,exception-ptr>' for
> handling <success|error|exception> to safely wrap throwing APIs.
>
> Documentation:
>    https://ned14.github.io/boost.outcome/index.html
>
> ACCU 2017 talk including design rationale:
>    https://www.youtube.com/watch?v=XVofgKH-uu4
>
> GitHub:
>    https://github.com/ned14/boost.outcome
>
> Latest tarball:
>    https://github.com/ned14/boost.outcome/releases/
> download/boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz
>
> Note:  Tarball might be easiest; but if you want to clone from GitHub
> directly, after the clone you should run the following command to get the
> source zip exactly:  git submodule update --init --recursive
>
> NEXT WEEK (when the public review is started):  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
>
> _______________________________________________
> 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
|  
Report Content as Inappropriate

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

Boost - Dev mailing list
On 13/05/2017 00:53, Soul Studios via Boost wrote:
> Sounds useful.
> I welcome a 'expected' implementation, even if, in my testing, results
> from this sort of thing are highly CPU-dependent and non-intuitive.

Can you clarify?

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
My apologies, when my brain saw "expected" it also saw
"__builtin_expect" and I immediately assumed an unlikely/likely proposal
- of course that's not what it is. My bad :)



On 13/05/2017 12:17 p.m., Niall Douglas via Boost wrote:
> On 13/05/2017 00:53, Soul Studios via Boost wrote:
>> Sounds useful.
>> I welcome a 'expected' implementation, even if, in my testing, results
>> from this sort of thing are highly CPU-dependent and non-intuitive.
>
> Can you clarify?
>
> Niall
>

_______________________________________________
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
On Sat, May 13, 2017 at 5:00 PM, Soul Studios via Boost
<[hidden email]> wrote:
> My apologies, when my brain saw "expected" it also saw "__builtin_expect"
> and I immediately assumed an unlikely/likely proposal

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!

_______________________________________________
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
On 14/05/2017 01:41, Vinnie Falco via Boost wrote:
> On Sat, May 13, 2017 at 5:00 PM, Soul Studios via Boost
> <[hidden email]> wrote:
>> My apologies, when my brain saw "expected" it also saw "__builtin_expect"
>> and I immediately assumed an unlikely/likely proposal

Ah, okay thanks.

> 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!

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.

GCC devs apparently don't care enough to fix it despite multiple
persistent reports, and the feature is now useless on GCC >= 5. The
speaker recommended clang, especially very recent clang which is
apparently finally being competitive with GCC in generating very tight
code. I'd back that up, clang 5.0 is generating much tighter code with
Outcome than clang 3.x did, markedly so.

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.

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
On Sun, 14 May 2017, Niall Douglas via Boost wrote:

> 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.
>
> GCC devs apparently don't care enough to fix it despite multiple
> persistent reports, and the feature is now useless on GCC >= 5. The
> speaker recommended clang, especially very recent clang which is
> apparently finally being competitive with GCC in generating very tight
> code. I'd back that up, clang 5.0 is generating much tighter code with
> Outcome than clang 3.x did, markedly so.
>
> 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.

I looked for bug reports about __builtin_expect in gcc's bugzilla, and the
only relevant one I found was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 about using it in a
switch. Could you back your statement with some links? Otherwise it sounds
like FUD (at least the part about ignoring multiple persistent reports).

--
Marc Glisse

_______________________________________________
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 05/11/2017 06:19 PM, charleyb123 . via Boost wrote:

> GitHub:
>   https://github.com/ned14/boost.outcome

The code has a "boost-lite" submodule. Is that part of the 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
>> 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.
>
> I looked for bug reports about __builtin_expect in gcc's bugzilla, and
> the only relevant one I found was
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59521 about using it in a
> switch. Could you back your statement with some links? Otherwise it
> sounds like FUD (at least the part about ignoring multiple persistent
> reports).

It's possible my memory is faulty, but I don't think it was. It was a
very good talk, basically a long list with extensive microdetail of how
compiler version quirks get in the way of micro optimisation. Builtin
expect was but one of many in a long list.

The presenter, Jason McGuiness, is one of the more colourful regular
attendees at ACCU and from all my interactions with him to date, I would
be considering him to not be FUDing. He's presented similar material at
ACCU London talks and several others.

His slides for the ACCU talk aren't online yet, so I'm sent him a
LinkedIn request and I'll ask for a copy. I'll post a link here if I get
them.

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
>> GitHub:
>>   https://github.com/ned14/boost.outcome
>
> The code has a "boost-lite" submodule. Is that part of the review?

In terms of public API, only the single part of boost-lite's API exposed
in Outcome's public API which is boost-lite::tribool, which I exposed
specially into the reference docs at
https://ned14.github.io/boost.outcome/group__tribool.html

(Outcome provides ternary based logic as an extension. If the peer
review desires, we can fake hide tribool into namespace boost::outcome)

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.

(that said, constructive comments, especially bug reports, in the out of
scope stuff are welcome. There are likely to be a ton of them)

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
On Sun, May 14, 2017 at 7:44 AM, Niall Douglas wrote:
>> The code has a "boost-lite" submodule. Is that part of the review?
>
> 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.

Any part of the implementation is in scope for the review, and if
"Boost-lite" is not an already reviewed and accepted Boost library,
then aren't reviewers allowed to review its implementation (since it
is effectively part of the submission)?

Glen

_______________________________________________
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 code has a "boost-lite" submodule. Is that part of the review?
>
> In terms of public API, only the single part of boost-lite's API exposed
> in Outcome's public API which is boost-lite::tribool, which I exposed
> specially into the reference docs at
> https://ned14.github.io/boost.outcome/group__tribool.html
>
> (Outcome provides ternary based logic as an extension. If the peer review
> desires, we can fake hide tribool into namespace boost::outcome)
>
> 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.

This doesn't exactly inspire confidence.

When a library enters Boost and is distributed in Boost releases, there's no
longer any point of it duplicating Boost functionality under the hood
(without a very good reason); while not requiring Boost is understandable
for standalone use, in a Boost release Boost is by definition already
available.

In addition,

> then Outcome would [...] be auto generated by script from the standalone
> Outcome same as Boost.ASIO is

carries the unfortunate implication that Outcome in Boost may be, similarly
to Boost.ASIO, a second-class citizen that may lag behind the "real" Outcome
where the real development occurs.

And finally,

> then Outcome would gain a Boost.Build veneer...

libraries are much easier to review if they are already in their final Boost
form, ready to be copied into $BOOST_ROOT/libs/$library. It's understandable
that people don't want to invest into that final step until the library is
accepted... but it should also be understandable that going that extra mile
is a sign of commitment that speaks positively about the author and can
therefore tilt reviewers toward acceptance.


_______________________________________________
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 12:54, Glen Fernandes wrote:

> On Sun, May 14, 2017 at 7:44 AM, Niall Douglas wrote:
>>> The code has a "boost-lite" submodule. Is that part of the review?
>>
>> 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.
>
> Any part of the implementation is in scope for the review, and if
> "Boost-lite" is not an already reviewed and accepted Boost library,
> then aren't reviewers allowed to review its implementation (since it
> is effectively part of the submission)?

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)

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
>> 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.
>
> This doesn't exactly inspire confidence.
>
> When a library enters Boost and is distributed in Boost releases,
> there's no longer any point of it duplicating Boost functionality under
> the hood (without a very good reason); while not requiring Boost is
> understandable for standalone use, in a Boost release Boost is by
> definition already available.

Almost all usage of boost-lite is substitutable by Boost. You can switch
it with a macro. That code path is stale and likely won't work right
now, but it wouldn't take much effort to restore it if the peer review
demanded it. You may remember some years ago I developed a set of
switchable STL implementation bindings to let one switch a library
between Boost or the C++ 11 STL. Outcome uses those.

>> then Outcome would [...] be auto generated by script from the
>> standalone Outcome same as Boost.ASIO is
>
> carries the unfortunate implication that Outcome in Boost may be,
> similarly to Boost.ASIO, a second-class citizen that may lag behind the
> "real" Outcome where the real development occurs.

This is a chimera.

Standalone ASIO has only diverged significantly from Boost.ASIO because
standalone ASIO has become unstable due to all the changes flowing down
from developing the Networking TS. Chris has, quite rightly, kept
Boost.ASIO insulated from all that profound change. If the Networking TS
were not happening, standalone ASIO and Boost.ASIO would be in sync, and
for the record, if you really want an up to date Boost.ASIO, you can go
run ASIO's Boost.ASIO generation scripts and you'll get one.

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.

> And finally,
>
>> then Outcome would gain a Boost.Build veneer...
>
> libraries are much easier to review if they are already in their final
> Boost form, ready to be copied into $BOOST_ROOT/libs/$library. It's
> understandable that people don't want to invest into that final step
> until the library is accepted... but it should also be understandable
> that going that extra mile is a sign of commitment that speaks
> positively about the author and can therefore tilt reviewers toward
> acceptance.

Once again you jump to conclusions.

Outcome is header only and follows the Boost directory layout. You can
drop it into a Boost distro if you really want to, but there is no
point, it makes no use of Boost.

All the conformance unit tests sit in a single file, and because I knew
there would be the above complaint about missing Jamfiles, I made a
shell and batch script that lets you compile the unit tests and run them
without needing cmake. You'll find one for POSIX and one for Windows in
the test directory.

Quite a few libraries submitted to Boost recently came with cmake
instead of Boost.Build. Only after approval did the author make the
Jamfiles. There is precedent here.

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:

> 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?

Unless you also have a de-boostification script that would somehow allow you
to merge the PR and then automatically port the changes to the primary repo.


_______________________________________________
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 10:56 AM, Niall Douglas wrote:

> On 14/05/2017 12:54, Glen Fernandes wrote:
>> On Sun, May 14, 2017 at 7:44 AM, Niall Douglas wrote:
>>>> The code has a "boost-lite" submodule. Is that part of the review?
>>>
>>> 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.
>>
>> Any part of the implementation is in scope for the review, and if
>> "Boost-lite" is not an already reviewed and accepted Boost library,
>> then aren't reviewers allowed to review its implementation (since it
>> is effectively part of the submission)?
>
> 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?

i.e. There's no difference to them between reviewing
boost::outcome::x, boost::outcome::detail::y, boost_lite::z,
boost_lite::detail::t

If so, we're on the same page. We're on different pages if you're
asserting that reviewers not be allowed to review boost_lite::z or
boost_lite::detail::t in order to determine whether Outcome has an
acceptable implementation for Boost.

Glen

_______________________________________________
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

Why does the library make the types possibly-empty? I couldn't find the
answer in the documentation.


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