lodash like utility/algorithms library for D

aliak something at something.com
Sat Sep 29 12:40:14 UTC 2018


On Friday, 28 September 2018 at 17:33:04 UTC, Paul Backus wrote:
> On Friday, 28 September 2018 at 14:02:48 UTC, aliak wrote:
>> Hi,
>>
>> [...]
>
> Lots of good stuff here!
>
> I'm curious about your approach to `Expect`, since I've written 
> a version of it myself. How useful have you found being able to 
> use unexpected values of any type, as opposed to just 
> exceptions?

Thanks! Still all rough around the edges.

About Expect, I've found that being able to define a set of 
expected unexpected values is quite practical, and if they're all 
based on the class Exception then there're two problems. 1, it's 
a class so it comes with all those constraints. 2, there's no way 
to close the value domain over the unexpeceted (if that makes 
sense?). Also some functions (take the classic errono catastrophy 
in C) may want to return error codes as unexpected values that 
are ints, and at the same time have a valid value as an int as 
well.

I.e. by allowing you to define the unexepcted you could for 
instance:

enum JSONError {
   invalidKey, notString, notNumber
}

auto a = parse(jsonData);

a.getAsString("key").match!(
     (string value) => // yay
     (JSONError error) => // small domain of what went wrong
);

A bit contrived here, but it actually comes form production code 
(https://github.com/schibsted/account-sdk-ios/blob/master/Source/Core/JSON/JSONObject.swift).

Different language of course, but in that repo there's a type 
called Result, which is basically Expect. But in swift you have 
something called protocols, which lets you contstrain template 
types (in a different way than isInputRange works). And there's a 
standard protocol called Error. So you can do:

Result<T, JSONError> where JSONError is defined as:

struct JSONError: Error {} // conforms to error protocol.

There's actually a D DIP which could allow for similar behavior: 
https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md

But for now since D does not have that.

Another approach would be duck typying I guess. And make a 
isExceptionType trait in D that makes sure some functions are 
supported (i.e. msg, and that it can be constructed with 
__FILE__, __LINE__ ). I have not thought out completely how those 
semantics would work, just thinking out loud right now.





More information about the Digitalmars-d-announce mailing list