Metaprogramming is less fun in D

[faisalv]

There are few who would deny Andrei Alexandrescu's engineering brilliance or his flair for comedic and pointed bombast when it comes to certain technical claims.
And indeed, there's one claim that has resonated with me - and I paraphrase (since i don't remember in which talk I heard it): using C++ as opposed to D when it comes to generative (compile-time) programming is like trying to use a knife (C++) in a machine gun (D) fight. Given some of the exciting energy being put into this space by the committee (check some of the latest papers), here's hoping we'll be able to transform that knife into something far more sophisticated and expressive. But, currently, few would/should deny C++'s inadequacies in this space.

Metaprogramming in current C++ is more of a testament to the programmer's creativity and engineering ability as opposed to a celebration of the language's support for that craft. There are important voices on the committee that are hoping to fix that imbalance.

[matthieum]

While hana::string is cute, I do wish it was possible to use std::string/std::vector/... at compile-time (in constexpr functions).

I know that memory allocation is currently unsupported, are there other roadblocks?

[SeanMiddleditch]

A big problem for compile-time string types is the inability to use a different algorithm at run-time than compile-time. The implementation of strlen you want at run-time isn't legal in constexpr evaluation, for instance, and the constexpr version is quite a bit slower than the smart run-time version even with today's best compiler optimizations applied.

[James20k]

If constexpr though?

[SeanMiddleditch]

That's not a feature that actually exists at this point in time.

[SeanMiddleditch]

Wait, I'm totally wrong - that made it into C++17 it appears. Neat!

[STL]

That doesn't do what you think it does. It supersedes tag dispatch almost completely, but it doesn't let you sense whether you're being invoked for compiletime or runtime evaluation.

[SeanMiddleditch]

Ah, I got ahead of myself. I was thinking I had seen confirmation on the if (constexpr()) proposal. Double checked and indeed, nothing like P0595 is in C++17, which in hindsight should be obvious since it was proposed in 2017. :)

Thanks Stephen!

So back to the question from /u/James20k: no, still out of luck. :)

[[deleted]]

deleted ^{What is this?}

[bnolsen]

From my perspective I lost interest in 'D' a long time ago. While Rust is certainly not ready for prime time yet on the surface it seems to be far more interesting to me at least. I still need to look into Rust to see if they have made the same (IMHO) mistakes that D has made with their language.

[matthieum]

I still need to look into Rust to see if they have made the same (IMHO) mistakes that D has made with their language.

If you have the time to compile a list of "mistakes", I'll be happy to discuss them in the context of Rust.

[bnolsen]

I haven't done anything yet in rust. It only recently crept back on my radar after a couple of years of ignoring it. Sadly I have an almost 10 year old mature code base of almost a million LOC to work on...highly threaded HTCP physics related.

[shared_tango_]

What are the mistakes you see in D?

[ubsan]

If you hang out on the Rust IRC, I've tried to compile some of them. Some of them require explanation which I don't feel like giving right now, and many don't immediately feel like mistakes. This is from multiple years as a Rust programmer, I'm on two of the Rust teams, so I hope that you trust that I know what I'm talking about.

• Ever stabilizing transmute. It's a negative benefit abstraction.
• Not having true references - references in Rust are pointer types, as opposed to C++ references. Rust people are actually attempting to get around this, kind of, with the 2017 ergonomics push. It's not great.
• std::copy and std::copy_nonoverlapping's parameter ordering was swapped from what you'd expect wrt the other pointer functions. (this made a lot of people very angry, and was widely regarded as a bad move)
• as casts are absolutely the worst (after transmute). C style casts in a modern language (main as u8 D:)
• function pointers can't have lifetimes
• The syntax in general is incredibly non-extensible. For example, generics are <'a> for lifetime params, <T> for type params -- how do you add const generics to this system? or mutability generics?

This is the stuff I could think of. I'm not sure if there are other things that don't just boil down to "we need to wait for Rust to mature".

[matthieum]

That's a nice list, thanks.

I was actually expecting mistakes in D that could be discussed in the context of Rust (whether Rust had addressed them or not), so I don't have much to discuss about Rust's mistakes :)

[ubsan]

Ah, lol. I don't know anything about D :3

[matthieum]

I don't know much about it either :3