Re: expectations 0.1.0

2018-09-05 Thread Paul Backus via Digitalmars-d-announce
On Tuesday, 4 September 2018 at 22:08:48 UTC, Nick Sabalausky (Abscissa) wrote: I think you may be getting hung up on a certain particular detail of Vladimir's exact "draft" implementation of Success, whereas I'm focusing more on Success's more general point of "Once the object is no longer aro

Re: expectations 0.1.0

2018-09-04 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-announce
On 09/04/2018 12:05 AM, Paul Backus wrote: On Monday, 3 September 2018 at 21:55:57 UTC, Nick Sabalausky (Abscissa) wrote: By contrast, a function that returns an `Expected!T` does *not* force its caller to acknowledge it. If an error occurs, and the caller never checks value or hasValue...nothi

Re: expectations 0.1.0

2018-09-04 Thread Paul Backus via Digitalmars-d-announce
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk

Re: expectations 0.1.0

2018-09-03 Thread Thomas Mader via Digitalmars-d-announce
On Monday, 3 September 2018 at 13:00:05 UTC, aliak wrote: This would be great to have in D. Indeed, if it's really going into C++ D needs to think about how to handle that anyway if it wants to offer C++ ABI interfacing. Swift [0] has something similar, and personally after using it for a f

Re: expectations 0.1.0

2018-09-03 Thread Paul Backus via Digitalmars-d-announce
On Monday, 3 September 2018 at 21:55:57 UTC, Nick Sabalausky (Abscissa) wrote: By contrast, a function that returns an `Expected!T` does *not* force its caller to acknowledge it. If an error occurs, and the caller never checks value or hasValue...nothing happens. That's called squelching an e

Re: expectations 0.1.0

2018-09-03 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-announce
On 09/03/2018 02:49 AM, Paul Backus wrote: On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky (Abscissa) wrote: Note that the above has *nothing* to do with retrieving a value. Retrieving a value is merely used by the implementation as a trigger to lazily decide whether the caller wan

Re: expectations 0.1.0

2018-09-03 Thread aliak via Digitalmars-d-announce
On Monday, 3 September 2018 at 06:00:06 UTC, Thomas Mader wrote: On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev wrote: There are generally two classic approaches to error handling: std::expected is not the only thing on this topic going on in C++. There is also the proposal

Re: expectations 0.1.0

2018-09-03 Thread aliak via Digitalmars-d-announce
On Monday, 3 September 2018 at 06:49:41 UTC, Paul Backus wrote: To me, the only acceptable choices are for `Expected!void` to have the same lazy semantics as `Expected!T`, or for `Expected!void` to be removed altogether. Having one specialization be lazy and one be eager would be a nightmare f

Re: expectations 0.1.0

2018-09-02 Thread Paul Backus via Digitalmars-d-announce
On Monday, 3 September 2018 at 04:49:40 UTC, Nick Sabalausky (Abscissa) wrote: Note that the above has *nothing* to do with retrieving a value. Retrieving a value is merely used by the implementation as a trigger to lazily decide whether the caller wants `foo` or `tryFoo`. Going out of scope wi

Re: expectations 0.1.0

2018-09-02 Thread Thomas Mader via Digitalmars-d-announce
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev wrote: There are generally two classic approaches to error handling: std::expected is not the only thing on this topic going on in C++. There is also the proposal from Herb Sutter [1]. It's not a library solution and changes even t

Re: expectations 0.1.0

2018-09-02 Thread Nick Sabalausky (Abscissa) via Digitalmars-d-announce
On 09/02/2018 11:23 PM, Paul Backus wrote: This is a really clever technique. As you said, hard to say whether it's worth it compared to just throwing an exception normally, but still, really clever. IMO, it's worth it. First of all, it decreases the asymmetry between `Expected!void` and ot

Re: expectations 0.1.0

2018-09-02 Thread Paul Backus via Digitalmars-d-announce
On Monday, 3 September 2018 at 00:52:39 UTC, Vladimir Panteleev wrote: Please correct me if I'm wrong, but from looking at the code, given e.g.: Expected!void copyFile(string from, string to); nothing prevents me from writing: void main() { copyFile("nonexistent", "target"); } The success va

Re: expectations 0.1.0

2018-09-02 Thread Vladimir Panteleev via Digitalmars-d-announce
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk

Re: expectations 0.1.0

2018-09-02 Thread Paul Backus via Digitalmars-d-announce
On Sunday, 2 September 2018 at 23:38:41 UTC, Per Nordlöw wrote: On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expecte

Re: expectations 0.1.0

2018-09-02 Thread Per Nordlöw via Digitalmars-d-announce
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk

expectations 0.1.0

2018-09-02 Thread Paul Backus via Digitalmars-d-announce
expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk, "Expect the Expected" [3], explains the advantages of this app