I've absolutely no D experience, but maybe others do:
I wonder, if a nice and friendly library uses features like this to provide a fancy embedded DSL, would compile-times suffer? If so, by how much?
Say, you could make something like LINQ entirely from inside a library using methods like these. Strongly typed ORM-ish methods that depend on the data model in use, even, maybe? Would that be too slow?
The more you do at compile time the longer compilation will take, of course. It's hard to say how much something like that would affect compile time without actually doing it. The official compiler, dmd, is already incredibly fast though (the 182,955 line standard library phobos built in 9.254 seconds on my machine) so you have a lot of headroom to work with.
First, bear in mind that there's no way to obtain or return an AST, so you're extremely limited in terms of what you can provide in a DSL. If you want to do anything beyond a certain level of complexity, the library user will have to pass in everything as string literals, and even then there are issues; your library's API will be indistinguishable from one that operates at runtime, but be much harder to implement, for starters.
Additionally, though this may have changed since, last time I used D extensively the CTFE was plagued by performance issues and memory leaks. In fact, it was ran with no GC at all.
I wonder, if a nice and friendly library uses features like this to provide a fancy embedded DSL, would compile-times suffer? If so, by how much?
Say, you could make something like LINQ entirely from inside a library using methods like these. Strongly typed ORM-ish methods that depend on the data model in use, even, maybe? Would that be too slow?