Re:Ownership and Borrowing in D
by WalterBright on Tuesday July 16, 2019 @01:56AM
(#20447783)
D deliberately restricts what compile time code can do that involves the operating system, restricting it to simply reading files from the current directory and down.
This is to prevent the use of the D compiler as a malware target by sending it specially crafted source code to compile.
Unfortunately, these restrictions make it hard to implement F# style Type Providers. Though honestly the filesystem one is not nearly as annoying as the inability to reinterpret-cast.
Re:Ownership and Borrowing in D
by WalterBright on Tuesday July 16, 2019 @05:27AM
(#20448625)
That's fine with me. I don't want to make the cross site scripting mistake.
Which happen to be currently broken on modern .NET runtimes because it wasn't done on a clean way apparently.
couldn't you just link to a c file in the same dir then use that to read up the file tree. I would be interested to know how D would prevent this.
Re:Ownership and Borrowing in D
by WalterBright on Tuesday July 16, 2019 @05:16AM
(#20448585)
D files don't #include .c files.
> Go actually has a built-in "Go generate" command that will look for magic "//go:generate <command>" comments in the code and automatically run code generation based on them, although I'm not sure how ergonomic it is.
But it's still not run automatically at build time, you have to go out of your way to run `go generate`, which isn't gonna happen if you, as is customary, fetch and build third-party code with `go get`.
> which isn't gonna happen if you, as is customary, fetch and build third-party code with `go get`.
Except that the convention is to check in the files generated by go generate, so in practice, it's not actually a problem.
Go actually has a built-in "Go generate" command that will look for magic "//go:generate <command>" comments in the code and automatically run code generation based on them, although I'm not sure how ergonomic it is.
>It just allows you to logically separate build time I/O from runtime I/O, which I find is nice for reproducibility of builds and maintainability of code.
This is a reasonable argument. For what it's worth, compile-time IO in D is more limited than in e.g. Haskell, as it seems the only compile-time IO D supports is reading files (or at least I can't find any documentation suggesting otherwise). Most of the power of its compile-time code execution comes from non-IO code (e.g. generating an optimal lookup table for a dictionary of values known at compile time, hard-coded in the code, or automatically generating fast JSON serialisation/deserialisation code for a struct without need for macros). While Rust also plans to support this, full support could be years away, while D supports it now.
>As far as your comment about databases, you should look at Diesel. It handles this very nicely in Rust, so... that’s not a problem at all.
Definitely shows it's possible to get the benefit of type providers without language support for them, hats off to the Diesel team!
>Is it compatible with 100% of the code that the current DMD release is compatible with? That’s all I ask for in alternate compiler implementations... but it seems like a lot, sometimes.
It's eventually compatible, sometimes lagging a few versions behind. Using LDC for release builds is somewhat comparable to only using stable Rust for release builds, except D has a slower pace of new feature additions than Rust since it already has so many features.