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