Am Montag, dem 10.03.2025 um 19:30 -0400 schrieb John McCall:
> On 10 Mar 2025, at 18:30, Martin Uecker wrote:
> > Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall:
> > > >
..
> >
> > > >
> > > > > > While the next example is also ok in C++.
> > > > > >
> > > > > > constexpr int n = 2;
> > > > > >
> > > > > > struct foo {
> > > > > > char buf[n];
> > > > > > };
> > > > > >
> > > > > > With both declarations of 'n' the example has UB in C++.
> > > > > > So I am not convinced the proposed rules make a lot
> > > > > > of sense for C++ either.
> > > >
> > > > If C required a diagnostic in your first example, it would actually
> > > > put a fair amount of pressure on the C++ committee to get rid of
> > > > this spurious UB rule.
> >
> > Why would C want a diagnostic here?
>
> When I said “your first example”, Martin, I did actually mean your
> first example:
Sorry, I meant "there". No reason to be condescending though.
> But I think it’s clear that you and I just differ on some basic design
> philosophy, so let’s just end the conversation here.
I think the issue that if one does not agree with the
design decisions made previously for the name lookup rules
in the C and C++ languages and wants to change those (or
adding new inconsistent ones), then this is not simply
a question of language design preferences.
Martin
>
> John.
>
> > > > > > I still think one could use designator syntax, i.e. '.n', which
> > > > > > would be clearer and intuitive for both C and C++ programmers.
> > > >
> > > > This doesn’t really solve the ambiguity problem. If n is a field name,
> > > > a programmer who writes __counted_by(n) almost certainly means to name
> > > > the field. “The proper syntax is .n” is the cause of the bug, not its
> > > > solution.
> >
> > Field names in C are in a different namespace. So far, when you write
> > 'n' this *never* refers to field member in any context. And I have
> > never seen anybody request a warning for the examples above. So, no,
> > "a programmer almost certainly means this" can not possible be true.
> >
> > Martin
