In article <01bc5bc3$7a27a4a0$c7fad5cc@MentorComm.neca.com> "Thomas C. Fulton" <fulton@neca.com> writes:
>I had heard that there was a change being considered which would cause loop
>control variables in an "if" statement to have a scope the the if statement
>itself, rather than the block enclosing the if statement. For example:
>
>if (int a = 0; a<5; a++)
>{
> // a would only be visible within these braces
>}
>
>if (int a = 0; a< 5; a++)   // this is legal

Your talking about the "for" statement not the if statement.
("if" statements are now allowed to declare something too, but doesn't
quite use the syntax you show -- but BTW, if's were exactly related
to this as to why the for statement needed to be "cleaned" up).

>Currently, a variable declared this way is visible and available from the
>point of declaration to the end of the block in which the if statement
>appears:
>
>if (int a = 0; a< 5; a++)
>{
> // a is available within these braces
>}
>
>// a is also available here.
>
>if (int a = 0; a< 5; a++)   // this is an error, a is redeclared
>

Correct (again, replace if's with for's).

>Has this change been implemented?  Is it planned?

It's been in the ANSI/ISO draft document for a good while now.
Compilers support it too.

> I have a problem with it,
>because it will cause existing code to break, for frankly the minimal
>benefit of being able to reuse a line of code.

Before the change folks debated that way.
Now that it's been changed, folks will debate about the new way.
Not breaking code is a good thing to consider, but really, in the grand
scheme of things, this one not something to get too worried about.

As well, there are pros and cons to the old and new ways.
I or somebody can enumerate if you're interested.
As you mention, this is minimal.  If you have a lot of code that
is not going to fly with the new rules, then get a compiler that
allows you to disable the new way.  Nonetheless, it's the (draft) spec
now and unless we're talking about real legacy code, you're best
conforming.  What's nice is that you don't need to literally look
for the cases: if the id is used after the scope of the loop, there
will be an error.  Compilers, as a quality of implementation issue,
might also choose to emit a notice about a difference id of the same
name in an outer scope that would end up being used.  If you want the
old way, then declare the id just before the for loop.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I had heard that there was a change being considered which would cause loop
control variables in an "if" statement to have a scope the the if statement
itself, rather than the block enclosing the if statement. For example:

if (int a = 0; a<5; a++)
{
 // a would only be visible within these braces
}

if (int a = 0; a< 5; a++)   // this is legal

Currently, a variable declared this way is visible and available from the
point of declaration to the end of the block in which the if statement
appears:

if (int a = 0; a< 5; a++)
{
 // a is available within these braces
}

// a is also available here.

if (int a = 0; a< 5; a++)   // this is an error, a is redeclared


Has this change been implemented?  Is it planned? I have a problem with it,
because it will cause existing code to break, for frankly the minimal
benefit of being able to reuse a line of code.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]