Jonathan Blow (cult/indie game developer/studio owner) has a lot of ideas about evolving C++ (or rather, building a new language to replace it) specifically in a game industry context. This perspective is interesting because its kind of running at a different angle away from the "memory-safe, better guarantees" project that Rust is workin on.

https://www.youtube.com/watch?v=TH9VCN6UkyQ

Just as the scripting languages took a big bite out of C/C++ usage starting in the 90s, I think we're seeing another couple use-case for C/C++ pull off:

1) stuff that is performance sensitive but security sensitive as well (Rust) 2) stuff that is soooo performance sensitive that Rust and C++ are actually too bloated, but which isn't really security sensitive so the guarantees that Rust/Modern C++ offer aren't worth it (Jai, Blow's language).

Category 1 is clearly real, but Category 2 might be too small to sustain itself (though Blow makes an economic argument that it would be worth it).

Are we just going to keep peeling back C/C++ users from the pack with more specifically-useful languages until there are none left except for those maintaining legacy code? Or are there use-cases where C++ will continue to make sense?

I guess a lot of this depends on whether or not we can meaningfully "modernize" C++ through the standards process without simply bolting on a lot more features that add to the bloat. I wouldn't wager much that this trick can be pulled off.

The interview covers proposed metaprogramming features in upcoming versions of C++. In particular, it demonstrates metaclass as a way for users to define new kinds of types, instead of relying solely on class/struct/union/enum.

For example, Java has an interface, in which methods are declared but not defined. The proposal for metaclass gives a demonstration of what an interface in C++ could look like:

    interface Shape { 
        int area() const;
        void scale_by(double factor);
    };

    // the dollar sign ($) prefix indicates reflection and metaprogramming
    $class interface {
        // the constexpr indicates compile-time execution
        constexpr {
            // raise an error if there are data members
            compiler.require($interface.variables().empty(),
                             "interfaces may not contain data");

            // loop over all functions
            for (auto f : $interface.functions()) {
                // raise an error if move/copy functions are present
                compiler.require(!f.is_copy() && !f.is_move(),
                                 "interfaces may not copy or move");

                // function must be public
                if (!f.has_access())
                    f.make_public();
                compiler.require(f.is_public(),
                                 "interface functions must be public");

                // function must be virtual
                f.make_pure_virtual();
            }
        }

        // add a destructor
        virtual ~interface() noexcept { }
    };

See the full proposal here:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p070...

Are they really going to add $ to C++? Unbelievable. What was wrong with "reflexpr"? It is way more C++'ish than "$".

Update: From Herb's blog :

"Also, a vocal minority in the committee strongly want a syntax that does not include the $ character (not just for $class, but also for $expr reflection) because they have large code bases that use $ in source code that is not C++ code but is processed to emit C++; removing $ is an easy change at any time and we’ll just follow what the committee decides for reflection syntax (in fact, the alternative syntax I showed in the endnote above removes the need to write $). So further work is needed on those items, but fortunately none of it affects the core model."

https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-ge...

P.S. I really hope that vocal minory would win ;)

But overall the proposal is what I have been talking about for a long time.

I sort of want a file-by-file language upgrade like Objective-C seems to have. For instance, if you add something like “nullable” to an Objective-C header, then the compiler will require similar directives throughout the file; otherwise, it doesn’t.

C++ needs a new strict set of rules that (ideally for individual files, to start) prohibits some set of older/deprecated features from even compiling. That way, you know where the language is going and you adapt.

This sounds to me like "we will make it simpler by adding more features (that are presumably simpler to reason about)." The problem with C++ (and the reason that it is too complex) is that it has too many features. This proposal will do nothing to eliminate all of the cruft, the real source of complexity. That would require actually removing features, backwards-compatibility be damned!

Yeah Metaclasses in Python are obviously so powerful and make programs so easy to read, so let's just go ahead and add those as well.

Now we only write

    struct Point {
        int x;
        int y;
    };

    class Point {
    private:
        int x;
        int y;
    public:
        Point() =default;
        ~Point() noexcept =default;
        Point(const Point&) =default;
        Point& operator=(const Point&) =default;
        Point(Point&&) =default;
        Point& operator=(const Point&&) =default;
    };