On Wed, Mar 12, 2025 at 3:28 PM Yeoul Na <yeoul...@apple.com> wrote:
> > On Mar 12, 2025, at 2:51 PM, John McCall <rjmcc...@apple.com> wrote:
> >
> > On 12 Mar 2025, at 16:02, Bill Wendling wrote:
> >> Qing pointed out in four lines of code how there are two different
> >> token resolution rules being used: one which is reliant upon C's
> >> current scoping rules and the other which requires a completely new
> >> scoping rule. This is no longer a question about what a programmer is
> >> most likely to infer what is meant or if the documentation makes it
> >> clear what's happening or any other ambiguous issues that me and
> >> others put forth before. This is a serious problem. There are
> >> essentially two options we have:
> >>
> >> 1. Create a proposal to the C standards committee adding an "instance
> >> scope" into the language and use that for the feature, or
> >> 2. Find some other way, which doesn't require modifying the base language.
> >
> > We are actually planning to write a paper for the C committee, so if
> > you’re willing to wait for that, perhaps that’s the right path forward.
> >
> > John.
>
> Let me clarify. We never proposed to change the base language. Please check
> my earlier response to Qing:
>
> > Yes, I read it and thanks again for writing it up! One clarification
> > related to that is -fbounds-safety never proposed to change the existing C
> > behavior. It’s adding an instantiation scope for the bounds annotations
> > only so members can be accessed within that context, this is similar in a
> > way to your __self proposal in that it’s introducing an instantiation scope
> > so that it can be only accessed through the __self syntax.
I don't think any of us intended to change the base language, but from
my reading of Qing's writeup we are. And I don't agree that __self is
also adding an instance scope. It's a way to reference the current
object, similar to 'this' in C++. Any reference to members within that
object must be resolved by reference: __self.member, etc. The members
aren't resolved by resorting to a scoping rule.
> > Then, the question would be potential confusions caused by inconsistency
> > with how array sizes are handled. However, trying to make it consistent
> > with arrays could actually make the counted_by itself more error-prone and
> > confusing because they are inherently different: arrays can never reference
> > members while counted_by should be able to. I’ll share our full reasoning
> > with examples in the RFC that I’ll post soon.
This is exactly why we're suggesting the '__self' (or maybe another
idea). :-) It removes all inconsistencies without adding a new scoping
rule to the language. However, as I said in my last email, we're past
worrying about user confusion because we really shouldn't change the
base language (adding a new scoping rule) in ways that haven't yet
been approved by the standards committee.
> > And the confusing code like below should be able to be handled by
> > diagnostics. The code like this is already confusing to readers and writers
> > of this code no matter which approach we will take and how clear it would
> > be for the compiler and the standard.
> >
> > void boo (int k)
> > {
> > const int n = 10; // a local variable n
> > struct foo {
> > int n; // a member variable n
> > int a[n + 10]; // for VLA, this n refers to the local variable n.
> > char *b __attribute__ ((counted_by(n + 10)))
> > // for counted_by, this n refers to the member variable n.
> > };
> > }
>
>
>
> We will share our RFC to this audiences by (hopefully) this week about how we
> design the bounds extension without changing the base language. The target
> audiences are people in this thread and compiler implementers.
>
> And separately we are also working on proposals targeting the C committee,
> unlike RFC for compiler changes, this may include some suggestions to change
> the base C language as well.
Thanks,
-bw
