Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Scope of identifiers Date: Mon, 12 Jun 2017 13:19:00 -0700 Organization: None to speak of Lines: 60 Message-ID: References:

<081872d4-3f9d-0004-8c0d-25a274bba7bb@verizon.net>

Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="defc4e5ae30e31482245c2bebee97ffa"; logging-data="16133"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/5Eocgpb02HAfUQbCnFPW2" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:fBHWLUO+85B/sUkx+has6CIxVdE= sha1:IcGyFoQ7Q7+q3ImcipvRN6iCo4I= Xref: csiph.com comp.lang.c:112081 "James R. Kuyper" writes: > On 06/12/2017 03:39 PM, Keith Thompson wrote: >> "James R. Kuyper" writes: > ... >>> I think the fundamental problem is at a slightly higher level. They had >>> two concepts of scope, and tried to use the same name for both concepts. >>> I think it would have been easier to describe things clearly if they had >>> used two different terms for the two concepts. I'll use "visibility >>> range" for one of the two, and "scope" for the other. Everything below >>> is my suggestion how the standard could be re-written for clarity on >>> this issue (it certainly does NOT describe what the standard currently >>> says). My intent is to leave the actual meaning of the standard's words >>> unchanged: if my suggestion fails to do that, it is my re-wording that >>> is at fault. >>> >>> Suggested conceptual reorganization: >> >> Summary: For a declaration in a block, an identifiers "visibility range" >> is the same as what the standard currently calls its "scope", and >> extends from the declaration to the end of the block. Its "scope" (new >> meaning) extends from the beginning of the block to the end of the >> block. (Glossing over, for now, what these terms mean for scopes other >> than block scope.) >> >> I haven't checked, but I can't think of anything in the standard that >> refers to your new wider "scope" other than the definition of the term >> "same scope". > > If you're right (and that seems plausible) I'd take that as a > justification for retaining "scope" for the first meaning, rather than > the second one. Reserve the new, more complicated term for the second > meaning. > >> A good goal, but I'm still not convinced that inventing a new term, >> rather than using something like "matching scope" rather than "same >> scope", is necessary. > > The term "matching scope" does not admit to a unique obvious meaning > that fits, so what it means for two scopes to match would have to be > defined. With an appropriate definition of some alternative term > ("extended scope"?), the meaning of "same extended scope" should be > sufficiently clear that it doesn't need to be explicitly defined. What you suggest calling an "extended scope" isn't really a scope (a region of program text within which a given identifier is visible). I'd rather not introduce a term such that an " " is not an example of a "". What I proposed was to replace the current definition of "same scope" (which is problematic because two non-identical scopes can be the "same scope") by something like "matching scope". (I'm open to a better adjective than "matching".) I think that solves the (minor) problem of "same scope" being confusing, it doesn't add to the number of defined terms, and it's a fairly minimal change. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"