lodash like utility/algorithms library for D
Paul Backus
snarwin at gmail.com
Mon Oct 1 00:51:24 UTC 2018
On Sunday, 30 September 2018 at 22:17:05 UTC, aliak wrote:
> On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus
> wrote:
>> I agree that this is useful, but why not just return a naked
>> `SumType!(string, JSONError)` in that case? Is there some
>> additional value added by the `Expect` wrapper that I'm not
>> seeing?
>
> That's an option as well I guess. But then you'd need to rely
> on convention and you couldn't do SumType!(int, int) f(), and
> Expect also gives you some more purposeful APIs that makes the
> code's intent clear. Plus I'm considering range behavior as
> well.
Is being able to write `Expect!(int, int)` actually desirable,
though? It seems to me like being forced to write something like
`SumType!(int, ErrorCode)` to distinguish the two cases would be
a good thing, even if ErrorCode itself is just a renamed int
(e.g., `struct ErrorCode { int code; alias code this; }`).
I guess you could argue that `return
typeof(return).unexpected(...)` is better than `return
typeof(return)(ErrorCode(...))`, which is what you'd get with
SumType, but they look equally ugly to me. What's really needed
to make that look nice is implicit constructors.
Treating an Expect as a range basically turns it into an
Optional, in the sense that it collapses any error information it
contains down to the boolean of empty vs not-empty. In fact,
probably the easiest way to add range behavior to Expect would be
to add a method that returns an Optional containing the expected
value, since Optional already has range behavior.
> Could you also return a union voldermort type then instead of a
> SumType?
Raw unions in D are horrifically unsafe, so I wouldn't recommend
it. If you want a voldemort SumType, you can get one like this:
auto f()
{
struct Result { SumType(T, U) data; alias data this; }
return Result(...);
}
More information about the Digitalmars-d-announce
mailing list