Re: lodash like utility/algorithms library for D
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(...);
}
Re: lodash like utility/algorithms library for D
On Saturday, 29 September 2018 at 19:27:29 UTC, Paul Backus wrote:
On Saturday, 29 September 2018 at 12:40:14 UTC, aliak wrote:
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
);
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.
Could you also return a union voldermort type then instead of a
SumType?
Re: automem v0.3.5 - now with more vector (like std::vector, not Physics)!
On Thursday, 20 September 2018 at 14:57:42 UTC, Atila Neves wrote:
If you've never heard of automem before, I wrote it to have
C++-style smart pointers in D that I could use in @nogc code:
http://code.dlang.org/packages/automem
Sorry for asking here.
Shouldn't this code work?
import automem;
struct X {
int i;
}
struct Y {
RefCounted!X x; // fails
//X x; // ok
}
void main()
{
Y y1;
Y y2;
y2 = y1;
}
https://run.dlang.io/is/k2qWhm
Re: LDC 1.12.0-beta2 (based on LLVM 7)
On Sunday, 30 September 2018 at 12:31:20 UTC, Dennis wrote: "LTO now basically working for Win64 too" That's great! Why the "basically"? Just a precaution as it hasn't been tested extensively yet; Guillaume Piolat (p0nce) successfully tested it with his commercial codebase though, so it's looking good. * New, Easy::jit-like interface for dynamic/JIT compilation. What are the applications of that? Is there a code sample I can check out? The linked PR contains some tests, but they aren't showcases. The dynamic compilation feature per se isn't new; its main application is probably for a bunch of hot key functions, compiling them at runtime to fully exploit the CPU's instruction set (and having the ability to treat some variables as const for these functions). You may want to contact Ivan Butygin (Hardcode84) for more infos, this feature is exclusively his baby. :)
Re: LDC 1.12.0-beta2 (based on LLVM 7)
"LTO now basically working for Win64 too" That's great! Why the "basically"? On Saturday, 29 September 2018 at 19:00:09 UTC, kinke wrote: * New, Easy::jit-like interface for dynamic/JIT compilation. What are the applications of that? Is there a code sample I can check out?
