Hacker News Reader

Comment by 112233 | Hacker News Reader

There is no hope for committee. In C++33 we will probably have variables defined as

    int const<const> auto(decltype(int)) x requires(static) = {{{}}};

And when asked how on earth did this happen and why, there will be the same "we must think about the existing code, the defaults were very poor"

Meanwhile they absolutely could make sane defaults when you plonk "#pragma 2033" in the source (or something, see e.g. Baxter's Circle compiler), but where would be the fun of that.

They still use single pass compiling (and order of definitions) as the main guiding principle...

View on HN

The root issue is that the committe has no incentive to improve the language when the current situation enriches its key members, C++ is just the vehicle they co-opted to sell books, or consulting, on solving problems that they perpetuate.

I’m with you - the features they add are baffling.

> we must think about the existing code, the defaults were very poor"

What does adding bad features have to do with maintaining defaults?

A lot of totally deranged contortions in C++, if you are lucky to find someone sharing the "secret" committee discussions, end up being caused by interaction of ODR, ADL, decay and other equally disease-sounding features. Like, I'd like to know how many people that can use C++ comfortably could write implementation of std::move and std::forward without looking. Or even tell which is which. Actually, let's try:

    template<typename T> T&& function_1(remove_reference_t<T> &x) {
        return static_cast<T &&>(x);
    }
    template<typename T> remove_reference_t<T> && function_2(T &&x) {
        return static_cast<remove_reference_t<T &&> >(x);
    }

Which one is move and which is forward?

Now, since all this jenga must remain functional, the only option they have to try and fix stuff that is a complete misfeature (like "this" being a pointer) is either requiring you to write make_this_code_not_stupid keywords everywhere ("explicit", "override", ...), or introduce magic rewriting rules (closures, range for, ...)

some fixes go much lower, "decltype(auto)" being a pinnacle of language design that will unlikely be surpassed.

Why do you believe that `override` belongs in that category?

Because the more desirable fix was requiring explicit annotation for "new" virtual functions, and make silent hiding an error. Instead, we have situation where you have to write "override" everywhere to get the desired sane behaviour.

I agree that explicit annotation for overrides is desirable, but disagree that it alleviates the need for `override`. The fact that a method is introduced for the purpose of overriding is IMO important enough to justify an explicit annotation regardless, much like C# does it with `new` and `override`.

It's also not clear to me what this has to do with ODR, ADL etc. That is to say, it's obviously a problem with a historical design decision (implicit overrides) that now has to be kept for backwards compatibility reasons, making it impossible to require a `new` annotation above and beyond opt-in compiler warnings. But that particular problem is not a uniquely C++ one, seeing how implicit overrides are actually more common than explicit ones in mainstream OOP languages, largely because they have all inherited this choice from either Simula (as C++ did) or Smalltalk. C# is more of an exception in that regard.

Reply on news.ycombinator.com