sob., 3 wrz 2022 o 16:31 Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Saturday, 3 September 2022 11:19:01 -03 you wrote:
> > Then question what version of std lib will be described in standard text?
>
> The standard recognises no such thing today. It only recognises itself as the
> only version. You're missing a step.
>
> > I get some compiler and compile code using C++26 and then why I get X
> > instead of Y that standard demand?
>
> Usually, you don t. All the Core Language changes are judged based on how much
> they'd affect existing code, so the overwhelming majority remains completely
> unchanged in behaviour. The Standard Library is mostly additive, so the same
> rule applies.
>
> Changing something so the behaviour is intentionally incompatible is very
> rare. What you're even proposing has never been done. So again, you're trying
> to solve a problem that may not need solving in the first place, and you're not
> considering other solutions to the same problem. And you're tying the solution
> to other unrelated things that didn't need tying.
>

Yes, but as I said before this has cost too, any error made in the
library can't be removed easily.
Especially if it was done long ago. I simply check what the cost would
be of one of alternatives.

> > Compiler writers will try to choose best default that will work for
> > them and the community they support.
> > What they choose does not affect my idea.
>
> Indeed. Which is why you should not be mandating this by way of a Core
> Language feature. Let them have the freedom of mixing and matching.
>
> > > Why can't the markers be a compiler extension, like the __attribute__ is?
> >
> > Standard will be the reason for breaking ABI and it should provide
> > tools to fix the mess after that.
>
> Why? Don't get me wrong, it's nice if it did, but it doesn't have to. There
> are other tools. And as I've been saying all the time: you're not providing a
> possible solution, you're mandating that they break and that they use your
> solution. You're removing their choice of what fits best for them.
>

Mainly because most of the problems will land on the hands of the end
user and he will need
to mix and match code from different versions. And best would be if
same solution
would work in every compiler.

> > Attribute would only provoke to introduce different solutions that
> > make creating portable programs even harder.
>
> Why is one sequence of tokens worse than another sequence of tokens? I'm not
> following.
>

All compilers will have the same set of attributes? Another thing is
that you would need
add attributes on types that do not belong to you like form header
from external source.



> > But still was a major compiler for previous decades. Compilers could a
> > ABI break mandated by standard
> > treat as optional features. We have exactly the same situation today
> > in C++20 with modules or coroutines,
> > by default you can't use them even if they are part of the standard.
>
> No, we're not, because neither has required an ABI break. You can use them
> right now so long as you compiler supports them, and retrofitting them into
> existing code bases does not affect unrelated codebases in the same
> application, nor inter-communication between those sections of code.
>

Ok, my point was more that you do not get full C++ by default.
This is indead a different magnitude of change but some way it is precedens.

> > As long as there are switches that make the compiler fully conforming
> > and in the long run that switches become default, then the way to
> > reach the end goal is irrelevant.
>
> I agree with this statement in isolation.
>
> > > > As this I could make write in couple of weeks
> > > > where hacking the compiler will take multiple months. Of course aside
> > > > from two first steps (a and b),
> > > > as I could make it in a couple of days. But it will be useless to
> > > > prove anything aside from breaking linking with old code.
> > >
> > > Then please do so. You're making great claims; they require great
> > > evidence.
> > >
> > > But I think you'll need to hack an actual compiler, to prove it can be
> > > done.
> > Agree, for the committee to accept a proposal like this it would
> > need an already working compiler that has it. But in "exploration" stage
> > this is not so much needed.
>
> You also need the buy-in from the ABI people (who don't use this list) and
> from the major compiler developers. Have you approached them at all?
>

Yup, probably if this "experiment" will be solid enough to consider
publishing paper
then before it I will approach them.
For now I work using your feedback as it points out the most important
points to watch on.

> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals