Scopes in which __label__ can appear

[Gabriel Dos Reis]

"Zack Weinberg" <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > | Does your opinion change if I point out that the documented effect of
| > | __label__ has always been to give the label a local scope?  It happens
| > | only to work in the context of statement expressions, but the
| > | documentation doesn't say that.
| >
| > if it does not work in the context of statement expressions, what
| > usefulness would it have?  (This is a real question, not  a rhetorical
| > one). 
| 
| Abstractly speaking, there are two effects of __label__:
| 
| 1) It makes the label visible to 'goto' from a nested function.
|    (This one is not under discussion right now.)
| 
| 2) It narrows the scope of the label to the block in which the
|    __label__ declaration appears.
| 
| These two effects are clearly documented.  Whether or not we should
| have this extension in the first place is beyond the scope of this
| discussion.
| 
| If __label__ did not narrow the scope of the label to the block in
| which it appears, it would be useful only for making the label visible
| to 'goto' from a nested function.  I suspect that this effect is
| rarely used, compared to the scope-narrowing effect.

Yes, and even then the identifier from enclosing scopes are still
visible in the nested function.

| Now, in the present implementation, if __label__ appears at nested
| block scope, but the nested block in question is not a statement
| expression, effect (2) does not happen.  I am convinced that this is
| an accident of the implementation, not an intentional behavior.

I do not have the log to see whether it is an accident or not (it
probably is one) but my claim is that because labels have function
scope, it does  make sense that effect (2) is suppresed  if the nested
scope is not a statement expression scope.

|  There
| is no particular reason (from a language design point of view) why the
| scope-narrowing effect should be limited to statement expressions.

Consider this:

   int f(int i) 
   {
     if (i > 9) 
       goto l;

    // ....
    if (i < 6) {
       __label__ l;

      l:
      return 0;
     }
 
     return i + 1;
   }

In parallel to your argument, there is no particular reason to reject
the above. 

| 
| Does that answer your question?

Yes.  Thanks.

-- Gaby