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.

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...

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.

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.

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;
    };