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

> On Tue, Jun 11, 2024 at 2:18 PM Jonathan Wakely wrote:
> >
> > What's a miranda function?
>
>
> I learned C++ from the book "C++ For Dummies" back in 2002. The author
> Stephen R. Davis wrote:
>
> "I like to call the Miranda functions, ie. if you can't supply
> your own, the court will supply them for you"
>
> Miranda functions are, for example, copy constructor, move
> constructor, assignment operator and so on. Anything that's given to
> you without you needing to ask for it.
>
>
> > Why can't explicit(false) be used here?
>
>
> That syntax could work too.
>
>
> > Why is making constructors explicit by default related to
> > making special member functions omitted by default?
> > Those seem like two unrelated features.
>
>
> The idea of marking a class as 'explicit' is just to make it very
> restrictive in many ways. Some people like to be very concise when
> writing code. I like to be pedantic and verbose, as in: "I want the
> compiler to ask me to clarify what I meant to do unless I've made it
> crystal clear what I meant to do".
>
> There is a majority of neurotypical people and a minority of
> neurodiverse people in society. Some estimate that the ratio is 99:1.
> When it comes to computer programmers, that minority is a lot bigger,
> with a ratio of something like 13:1. And as you go up in skill level
> with computer programmers, that ratio gets closer and closer. If we
> were to survey all of the people who compose papers to present to the
> C++ committee, I'd believe you if you told me half of them were
> neurodiverse.
>
> The reason I'm getting into all this is that I think a lot of
> programmers want the compiler to demand more clarification from the
> programmer. That's why I dug up posts from 3 other people over the
> past 22 years to show that other people want this too.
>

That's still not motivation. If you want to define special members as
defaulted or deleted, you can already do that (by writing it explicitly -
which is surely even more explicit!). If you want to prefix every member
access with this-> then you can do that too.

What is the benefit of a new language feature that *forces* you to do that,
except satisfying a personal preference for coding style? Why not write a
clang-tidy checker for this? Why does it need to be a first class language
feature?




>
>
> >> 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'.
>
>
> I like to have "virtual" on the far left because when you're scrolling
> down through the header file, you see the "virtual" first (as we
> normally read from left to right). Maybe programmers who started out
> with Hebrew or Arabic will have a stronger tendency to look to the
> right (but even readers of Hebrew and Arabic will be used to the text
> being aligned on the right, so when it's unaligned on the right then
> maybe they're more likely to look to the left). I want to scan my eye
> down the left side of the screen and immediately see which methods are
> virtual.
>
> Why should a language feature be introduced for a personal preference?
Write a clang-tidy check.


>
> > wat
> >
> > This seems a lot less bizarre:
> > virtual func() override(false)
>
>
> When I see your line of code, I think:
>
> "This is a virtual member function, and there is no such virtual
> function in any of the base classes"


> But I wanted to convey:
>
> "This is a virtual member function, and there is a non-virtual
> method with the same name in at least one of the base classes"
>
>
> > 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?
>
>
> For example when you see a function like:
>
> void SomeClass::SomeFunc(void)
> {
> SomeOtherFunc();
> }
>
> You don't know if "SomeOtherFunc" is member function. I prefer to write:
>
> void SomeClass::SomeFunc(void)
> {
> this->SomeOtherFunc();
> }
>
>
>
Personal preference. Why is a new language feature needed to please you and
three other people in 20+ years? Write a clang-tidy check.



> >> 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?
>
>
> Some would argue that the 'typedef' is a workaround for a lack of
> restrictiveness.
>

Some would argue that naming a member the same as a base class is silly
anyway.