On 28/2/25 02:09, Brian Bi wrote:
>
>
> On Wed, Feb 26, 2025 at 7:19 PM Russell Shaw via Std-Discussion <std-
> discussion_at_[hidden] <mailto:std-discussion_at_[hidden]>> wrote:

...

> The reason why it's not ambiguous is that the E subobject contains all A and B
> subobjects of an F object.

I'll research more about the area from earlier papers.

> If you want a stricter rule, e.g. that lookup finds E::x unambiguously only if
> every path to an x passes through E, then you should try prototyping it in a
> compiler and seeing how much code it breaks.

It would break a low percentage of code that now would not compile, and so would
need to be fixed to not utilize semantics that allow ambiguous behaviour.

The g++ ecosystem works ok by disallowing the ambiguity.

Before prototyping it in a compiler, or being proficient at just using the
language, i need to fully understand it.

It would be much better if the standard explained things in terms of pseudo code
algorithms instead of being full of ambiguous english constructions devoid of
context.
> I expect you'll find that, in this particular case, it's easier to realign your
> expectations with the standard than it is to change the standard.

I would rather follow the standard if i can find how it justifies the behaviour.

If the result is "only for compatability with previous behaviour", that would be
bad (to me).