On Tue, 11 Jun 2024 at 13:56, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> If you do a quick Ctrl + F search on the C++ proposals history on this
> webpage:
>
> http://www.virjacode.com/cxxproposals/
>
> There are three threads which propose the idea of an "explicit class":
>
> 2023 : https://lists.isocpp.org/std-proposals/2023/04/6184.php
> 2019 : https://lists.isocpp.org/std-proposals/2019/11/0700.php
> 2004 : http://virjacode.com/cxxproposals/compstdcxx/article18301
> 2002 : http://virjacode.com/cxxproposals/compstdcxx/article27185
>
> There might be more threads that pose the same idea but call it
> something other than "explicit class". So I think we should write a
> paper to describe "explicit class" which you would use just like
> "class":
>
> explicit class Dog {
> public:
> int n;
> Dog(void) = default;
> virtual int Get(void) { return this->n; }
> };
>
> So far, here's what I'm thinking the five differences should be in
> 'class' Vs 'explicit class':
>
> 1 - All miranda functions are deleted. Specifically, all
> constructors and assignment operators are deleted. If you want any
> miranda function, you must write " = default; ".
>

What's a miranda function?


>
> explicit class Dog {
> public:
> int n;
> Dog(void) = default;
> };
>
> 2 - When you define a constructor of your own, it is explicit by
> default unless you mark it "!explicit".
>
> explicit class Dog {
> public:
> int n;
> !explicit Dog(int);
> };
>

Why can't explicit(false) be used here?

Why is making constructors explicit by default related to making special
member functions omitted by default? Those seem like two unrelated features.

Maybe you have some rationale for coupling those features, that you're
keeping secret for some reason?



>
> 3 - A derived class's member function which overrides a base
> class's virtual function must be marked as both 'virtual' and
> 'override'.
>

Why? That goes against all guidelines I'm aware of, which say to omit the
redundant 'virtual' when using 'override'.


>
> class Frog {
> virtual int Func(void) { return 7; }
> };
>
> explicit class Dog : public Frog {
> virtual int Func(void) override { return 8; }
> };
>
> 4 - A derived class's virtual member function which has the same
> name as a base class's non-virtual member function, must be marked as
> "virtual(override !virtual)". This syntax is intentionally
> in-your-face and ugly to convey the danger:
>

wat

This seems a lot less bizarre:
virtual func() override(false)


> class Frog {
> int Func(void) { return 7; }
> };
>
> explicit class Dog : public Frog {
> virtual(override !virtual) int Func(void) { return 8; }
> };
>
> 5 - You must explicitly write "this->" before every member (both
> member variables and member variables). For example the following
> won't compile:
>
>
Why? What has this got to do with the other features?

Why should writing 'explicit' before the class-head enable a bunch of
unrelated features?
Is there any motivation for this?


> explicit class Dog {
> public:
> int n;
> Dog(void) : n(7) {}
> virtual int Get(void) { return n; }
> };
>
> but the following will:
>
> explicit class Dog {
> public:
> int n;
> Dog(void) : this->n(7) {}
> virtual int Get(void) { return this->n; }
> };
>
> Note that the constructor's initialiser list has "this->n(7)" instead
> of "n(7)", and this is so that you can have a member with the same
> name as a base class, as follows:
>

Why is that useful?
Why can't you solve it with a private typedef for the base class?



>
> class n {};
>
> explicit class Dog : public n {
> public:
> int n;
> Dog(void) : n(), this->n(7) {}
> virtual int Get(void) { return this->n; }
> };
>
> Anyone got any more ideas?
>

This seems like more than enough already.