Replace the uses of "local variable" with "[block] variable with automatic storage duration"

[frederick-vs-ja]

P1787R6 dropped the previous buggy uses and definition of term local variable. But there're many remaining use of local variable.

This PR removes the remaining occurences except for one "conceptual local variable" in a comment (which seems OK to me as we're not talking about real local variable).

Fixes #6617.

[jensmaurer]

I would prefer to replace the remaining uses of "local variable" with "[block] variable with automatic storage duration" for consistency, instead of reintroducing a term that CWG agreed to abolish.

[frederick-vs-ja]

I would prefer to replace the remaining uses of "local variable" with "[block] variable with automatic storage duration" for consistency, instead of reintroducing a term that CWG agreed to abolish.

Thanks. I'm now switching to this direction.

[FrankHB]

I would prefer to replace the remaining uses of "local variable" with "[block] variable with automatic storage duration" for consistency, instead of reintroducing a term that CWG agreed to abolish.

They are not equivalent. The term "local variable" has nothing to do with the storage duration at all, it is now just "block variable", not necessarily "with automatic storage duration"; although most use cases apparently imply this. And personally I don't like too many occurence of the lengthy "with automatic storage duration" phrase when the storage duration is contextually clear enough.

[jensmaurer]

@FrankHB , works for me; I haven't looked at the details. If we mean "block variable", we should say so. If we mean "with automatic storage duration", we also should say so.

[frederick-vs-ja]

And personally I don't like too many occurence of the lengthy "with automatic storage duration" phrase when the storage duration is contextually clear enough.

Yeah. I wish it's clear enough to suppose the automatic storage duration can be implied by not using static or thread_local in the library wording.

[tkoeppe]

Looks good, thanks! @jwakely could you have a quick look at the iostreams wording?

[jwakely]

Being this precise about the storage duration of hypothetical local variables used within locale facets seems unnecessary to me (is anybody going to interpret that wording as saying they should have static storage duration?!), but whatever, it's fine.

[tkoeppe]

Well, the main point is to get rid of the term "local". The proposed wording avoids any future complaints about potential ambiguity. In the non-normative examples we have indeed just dropped all qualifications, since it's clear from context what we mean, but in the normative wording it's perhaps worth being precise even if it's obvious.

[jwakely]

Understood, I just think using "variables" in the locale wording would have been fine. That wording has bigger problems!

[jwakely]

But I'm not suggesting a change - as you say, being explicit avoids potential future requests for clarification.

[tkoeppe]

Right... if you think the wording would be completely fine and beyond future reproach, I'd be happy to consider dropping the qualifications, but spelling it out seems a bit safer, since it would otherwise be open to questions (e.g. "Can the sentry be static? That's faster.").

[tkoeppe]

@frederick-vs-ja: would you mind digging up the affected subclause stable labels?