Hacker News Reader

Comment by mhh__ | Hacker News Reader

constexpr should just try to evaluate stuff at compile time. In D, most sensible code works at compile time automatically, I don't think about it.

Having to mark everything as evaluatable at compile time is a stupid, stupid, decision that only C++ could think was a good idea.

View on HN

It may seem stupid to you, because you only consider saving a few keystrokes. The keyword exist to guarantee stability/contract of compile-time-compatible APIs.

A change of an implementation detail in some leaf function (that happens to add a run-time dependency) should not accidentally break execution of another function elsewhere (possibly in a different downstream project) that happened to work as compile-time before that.

Note that compilers are still free to execute pure functions opportunistically at compile time, but it's just not guaranteed.

By the same logic it also means everything has to be marked as constexpr, i.e. you have to type everywhere, people who don't make their code less pleasant to use. The end game is that everything reasonable will be constexpr anyway, so there's no point.

One downside to implicit constexpr is its harder to know when an API intends it as a user and harder to enforce it works as an author. Seems like it could be easy to break compatibility.

At least users would notice at compile time when it breaks. With both implicit and explicit constexpr, authors who care could use the explicit form, and any implicit constexpr would be “use at your own risk”, but would still be guaranteed to work as long as you don’t upgrade the dependency.

That doesn't really happen in D because basically everything is "constexpr" unless it does something like inline ASM or unions with pointers in them

D should worry less how great language it is, focus on fixing long standing DIPs and compiler bugs, and actually have an ecosystem that makes it worthwhile using in the industries where C++ is the first choice.

Somehow it feels like languages are clashing here.

>D should worry less how great language it is,

You are just replying to some guy expressing an opinion on internet about how to do something better, and using D as example.

Mostly because unless I am going crazy, the comment was different when I posted my remark.

The HN guidelines state:

> Eschew flamebait. Avoid unrelated controversies and generic tangents.

You responded to

> Having to mark everything as evaluatable at compile time is a stupid, stupid, decision that only C++ could think was a good idea.

with

> D should worry less how great language it is, focus on fixing long standing DIPs and compiler bugs, and actually have an ecosystem that makes it worthwhile using in the industries where C++ is the first choice.

Definitely qualifies as both "flamebait" and "unrelated controversies".

The comment was edited, it was about the virtues of static if in D versus C++.

My comment?

If I recall correctly it had something about not doing if constexpr if being lesser than static if, and how greater it makes D over C++, overlooking the fact that since Andrei published its book that has mattered very little.

Now if I happened to reply to the wrong comment, sorry about that, and I should pay more attention before replying.

You have replied to the wrong comment.

> Having to mark everything as evaluatable at compile time is a stupid, stupid, decision that only C++ could think was a good idea.

What is stupid about it? It makes a lot of sense given how programming languages work.

What sense is that? I've worked on roughly 3 compilers with CTFE

Reply on news.ycombinator.com