n remove

wt., 2 sie 2022 o 13:05 Frederick Virchanza Gotham
<cauldwell.thomas_at_[hidden]> napisał(a):
>
> On Tue, Aug 2, 2022 at 10:18 AM Marcin Jaczewski wrote:
>
> > Then your proposal should be rejected on the spot.
> > All proposals NEED to have a use case and a big segment of users that
> > will use it.
> > Otherwise the cost of implementing it and maintaining it will not be justified.
> >
> > Not to mention that it makes it impossible (or very hard) to implement
> > other proposals than
> > touch v-tables. And some of them could have use cases and a lot of
> > users that could benefit from it.
>
>
> I'm not sure what you mean here. Are you saying that I shouldn't share
> provisional ideas about editing v-tables for fear that other people's
> ideas about editing v-tables won't be listened to? Or I have totally
> misunderstood? I'm not sure what you mean.
>

Goal of this mailing list is to propose changes to change C++,
And there are some important reasons/problems to make these changes.

What does your proposal/idea give us that is impossible in current C++?
Why should be this done?

If you do not have answers for this then it becomes noise,
because it will not affect future changes of C++.


>
> > Then make your own language and see how it will work, you can easily
> > experiment and
> > check some wild ideas and see what the result will be.
>
>
> I don't need to make my own language, I have a computer with internet
> access to this mailing list.
>
>
> > Every wrongly specific feature for C++ can have consequences that will
> > be pain for every one for decades.
> > See how much problems cause utf8 literals, or in python transition for
> > version 2 to 3.
> > Or even exceptions, if we go back in time and implement them as
> > "deterministic exceptions" could have
> > wider usage and not have a split in community.
>
>
> I agree that we should put bad features into the language. I don't
> think that's ever been done deliberately.
> I wouldn't want the editing of v-tables at runtime to make it into the
> Standard if it would only cause headaches.
>
>
> > And you propose that we will have another split, editable and not
> > editable v-table by compiler options.
> > Then we will have 4 versions of C++, and add RTTI that will be 8 versions.
>
>
> If you add "-pthread" and "-fshort-enums" then it balloons up to 32.
> Add "-fexceptions" and "-fPIC" and you're up to 128 versions.
>
> Although personally I wouldn't use the English word "version" in this context.
>

Btw "-fshort-enums" you can remove as it have already correct solution
in standard:
```
enum X : char;
```
Many other are because of some environment limitations,
like what floating point type should be used.

This mean correct solution at least for what you propose to be similar
to enum fix.
You define some tag at type that you are allowed to change v-table like:
```
class X mutable_vtable : Base {};
```
Or something like this, then no compiler switch will be needed.
And this will not bifurcate C++ environment as you could link both versions.


>
> > I can make a compiler without user options. This will be limiting but
> > still conforming.
> > If I need to use it only for very specific cases, why should I add any
> > new options?
>
>
> That's why I started this discussion, to get good suggestions for
> useful compiler options.