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.

> 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.

> 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.

> 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.

> 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?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering