> On Mar 10, 2025, at 11:04 PM, Martin Uecker <uec...@tugraz.at> wrote:
>
> 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
>
I won't speak for John, but the way I see it you can optimise for theoretically
consistent minimalist semantics, or strive to optimise each feature for its
most common use cases. That's a difference in design philosophy.
Although I don't think these ambiguities matter in practice (as long as there
are workarounds) since their occurrence will be vanishingly rare, the fact that
'n' currently means one thing doesn't mean that it should have to mean the same
thing in another context with different design goals, especially when that is a
completely new context. The context of "__counted_by(...)" surrounding the
expression should be enough to infer what is meant. The fact that code could be
structured in a way to mislead the reader is nothing new to C, and when the
context where that even could be a concern is largely hypothetical I don't
think eliminating it should be a priority.
Henrik
