Re: Scopes in which __label__ can appear

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark@codesourcery.com> writes:

| On Sat, 2003-07-19 at 12:52, Zack Weinberg wrote:
| > Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > 
| > > | > In parallel to your argument, there is no particular reason to reject
| > > | > the above. 
| > > | 
| > > | So the __label__ in this example has no effect at all?
| > >
| > > Basically,  I'm saying yes.  It would  be a no-op.
| > 
| > I don't like that, I think it'd be confusing and surprising to users.
| > I'd much rather either reject the code or narrow the scope of the
| > label (and therefore reject the code because the label isn't in scope
| > for the goto).
| > 
| > Also, from an implementation point of view, either of my preferred
| > options is cleaner than what you are suggesting.
| 
| I agree with Zack.
| 
| __label__ should have two effects:
| 
| #1: It makes the label accessible to a nested function.

This is  not under dispute.

However, you may notice that for a nested function, identifiers in the
enclosing scope are visible, so #1 is actually unnecessary.
But I'm not saying we should remove it, just noting that it is not
as essential as it is being stated.

| #2: It declares a label with block-scope, as opposed to the ordinary C
| function-scope label.  That is the effect that makes __label__ useful in
| statement-expressions.  

Again, for statement expressions, the issue is clear.  IT is not under
dispute.  

| In other words, this code:
| 
|   void f() { { __label__ l; l: ; } goto l; }
| 
| should be invalid.
| 
| The idea is that a label declared with "__label__" is just like an
| ordinary automatic variable; it "goes out of scope" at the closing curly
| brace of its enclosing block.

But there is nothing like "a lebel just like an ordinary automatic
variable".  Once you introduce that notion, you start confusing
people.  

| It would be very odd for it to work one way in statement-expressions,
| but another way elsewhere 

No, what is confusing is the notion os statement-expression.  They
don't act like anything else in the language.  Trying to have people
believe that statement-expressions act like anything else in the
language is creating promises and time-bomb confusion.
It should be made clear that statement-expression don't behave like
ordinary scopes. 

| -- you should be able to move code in and out
| of statement-expressions at will. 

Except that one does move code in and ou of statement expressions like
that; especially when they contain gotos.

If you make __lebel__ l; a no-op, you don't into the risk of 
  1) making it more and more used
  2) break potentially codes -- after all, we;ve got a testcase.

| A way to say that more formally is
| that the expression-statement:
| 
|   ({ /* Code here */ });
| 
| should be equivalent to the compound-statement:
| 
|   { /* Code here */ }
| 
| Now, in my ideal world, statement-expressions and __label__ would not
| exist.

In my world, they would not exist either.
(Currently, there are works going on -- in the C++ committees -- on
generalizing intializers, and if that proposal were adopted, the
syntax would immediatly clash with our famous statement-expressions).

| In my slightly-less-ideal world, __label__ would not have two
| semantic implications, but only one.  But, for now, neither of these
| options is on the table.

-- Gaby