On Tue, Jun 11, 2024 at 3:30 PM Jonathan Wakely wrote:
>
> Why should a language feature be introduced for a
> personal preference? Write a clang-tidy check.


You can throw that argument at a lot of good language features. A few examples:

- Instead of marking a constructor as explicit, use a 3rd party code
analysis tool to detect the use of an implicit conversion that uses a
constructor.
- Instead of deleting the move constructor, use a 3rd party code
analysis tool to detect the passing of an Rvalue of type
"decltype(*this)" to a constructor.
- Instead of marking a virtual function as " = 0 " in the base class,
use a 3rd party code analysis tool to ensure that an object of the
base class is never created by itself, and that any derived classes
override the base class's virtual function.
- Instead of marking a variable as 'const', write a comment " // never
changes" after the variable declaration, and use a 3rd party code
analysis tool to detect the changing of the value of a variable that
was declared with " // never changes" after it.
I can go on and on.

In my original post, I listed 5 effects of "explicit class":
    - All miranda functions deleted by default
    - Any constructor is 'explicit' by default
    - Overridden functions must be marked 'virtual override'
    - Must confirm to compiler that you realise you're overriding a
non-virtual with a virtual
    - Must write "this->" before every member

Maybe I'm going a bit far with it now, but maybe we could opt
individually into the restrictions:

    class MyClass
restrict[no_mirandas,explicit_default,must_mark_override,nonv-mark-override,must_this]
{
    };

Of the five effects I listed above, the two I'm most interested in are:
    - All miranda functions deleted by default
    - Must write "this->" before every member

Maybe other people are more interested in the other three?

Also another new restriction I would like is demonstrated in the
following program:

    struct monkey {};

    int monkey;

    int main(void)
    {
        monkey = 5;
    }

It was a really really really bad idea back in the 1970's to allow C
to give a struct the same name as a variable. I would like to see this
deprecated in C++26, and made a compiler error in either C++29 to
C++32.