lodash like utility/algorithms library for D

[aliak]

On Monday, 1 October 2018 at 00:51:24 UTC, Paul Backus wrote:
> 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; }`).

Hard to say, I would try to avoid it if possible, but why should 
it not be allowed if someone wants it? For now it feels like an 
opinionated restriction that I think is better left out of 
generic code when possible - at least for now. If it turns out 
otherwise I'll change it - this is all still quite experimental 
in me head.

Using SumType to denote success and failure would be more of a 
convention though and would make for more "huh?" moments for 
readability/maintainability, IMO. I like typing intents.

And being able to add an "alias this" in Expect for e.g. might be 
nice. Or if I want to add a "make match has exactly two handlers" 
so that you have to handle both cases would also be a plus.


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

*nods*

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

Good point. Agreed!

>> 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(...);
> }