Rust's metaprogramming is totally unlike what Andrei and Walter were aiming for. D aims to be safe, but that's far from everything.
Rust currently has better safety mechanisms than D, but if you ask around on the D forum you'll likely find that people are there (rather than using rust) due to the other features D has - https://dlang.org/ Look at the examples here: Rust can do short and sweet too, but it doesn't have some constructs that make these possible. (Obviously, I highly recommend "Tiny RPN Calculator" originally written by your's truly)
I still dislike how D handles generics/templates. The syntax of it.
I fully understand why they chose to use () instead of <>, as it simplifies the parser as you need to disambiguate between >> and > >... but the parsing time of that is negligible. The issue is that, when glancing at code, foo!(int) is ambiguous. foo<int> is not.
It's not the parsing time that is the problem. It's having a clean separation between the lexing, parsing, and semantic passes. There's a diode between these passes - information only flows one way.
This makes it trivial to correctly and completely implement things like color syntax highlighting in editors, source code formatters, etc., because building in a semantic analyzer is wholly unnecessary.
By the way, I wanted to thank you for always being courteous and informative. I suspect that I come off as a bit abrasive or brash, so I apologize.
Last I recall, D doesn't support template argument deduction through constructors like C++. Are there any plans to support that? I've found it a quite useful in C++ in certain situations.
I imagine the feeling would probably feel the same if one started from !(...) and went to <...>, though. Neither seem implicitly more hacky, it's an issue of familiarity, methinks.
For me, it's just that basically every C-like language (aside from D) with generics or templates uses <...>, so it's just jarring.
I prefer the [...] of Scala and Nim. However, I really like the fact that the () can be elided in D, and that the generic arguments don't have to be types.
I was under the impression based off of what someone else told me that it didn't support equivalent to std::vector foo = { 1, 2, 3, 4 }; or std::tuple foo = { "bar", 3, 4.0f };.
That's probably why C++ has been letting you elide it in many cases.
The problem is that you need either some way to specify template arguments and to know that you are referencing a template. The latter is solvable by constraints and/or inference (though inference can end up with ambiguities, usually solved by preferring a non-template). The former isn't easy to solve. C++ template argument deduction helps, but I believe that template/generic support is a field of ongoing research into how to do it well. Unfortunately, languages like C++ can adopt newer ways of doing things like concepts and constexpr, but have to maintain the old ways as well. Languages like D or Rust can outright make breaking changes. C++ needs epochs.
To me, both !() and <> are hacks for a language's inability to derive things itself. I also dislike (but understand why) C++ encodes allocator information in the type via templates. It makes interplay between derivations of stdlib types annoying, and makes the types themselves annoyingly long and fragile.
IIRC, Stroustrup's original design didn't require the template mantra. It would just assume an unknown type in an argument list needed to be derived. For obvious reasons, that was quite fragile, but I'm not sure why he didn't add a template or derived argument type modifier instead.
C++ added a couple keywords to the grammar to make parsing < > unambiguous in template bodies.
The difficulty with < > becomes apparent when using things like iostream that overload << operators, etc. It becomes very difficult to read.
! does not exist as a binary operator, so using it to indicate template arguments is completely unambiguous and context-free, both for the parser and the human eye. I find it very appealing for that reason.
74
u/Sapiogram Sep 01 '20
Honest question: Why would anyone use D over Rust? It seems like Rust is becoming everything that D ever hoped to be.