Posted here because comp.std.c++ seems to have died an unexpected death.

-------

I note with some dismay the proposal to create a new meaning for the C and
C++ keyword 'auto', as described in the document N1984 (part of the
proposals for C++0X or whatever it's called now). Efforts are being taken to

ensure it doesn't conflict with the previous meaning of the keyword, but why

not simply have a whole new keyword? These guys aren't stupid, so I assume
there must be a good reason.

'Chops

Moschops wrote:
> Posted here because comp.std.c++ seems to have died an unexpected death.
>
> -------
>
> I note with some dismay the proposal to create a new meaning for the C and
> C++ keyword 'auto', as described in the document N1984 (part of the
> proposals for C++0X or whatever it's called now). Efforts are being taken to
>
> ensure it doesn't conflict with the previous meaning of the keyword, but why
>
> not simply have a whole new keyword? These guys aren't stupid, so I assume
> there must be a good reason.
>

Yeah, nobody used auto (it was a storage class specifier that specified
automatic storage, and since local variables are automatic by default,
and you can't use it elsewhere, what's the point?), and so it was
reused, to avoid adding new keywords. If you add new keywords, you risk
breaking existing code.

DISCLAIMER: IANAICM (I am not an ISO Committee Member)

Moschops wrote:
>
> I note with some dismay the proposal to create a new meaning for the
> C and C++ keyword 'auto', as described in the document N1984 (part of
> the proposals for C++0X or whatever it's called now). Efforts are
> being taken to
>
> ensure it doesn't conflict with the previous meaning of the keyword,
> but why
>
> not simply have a whole new keyword? These guys aren't stupid, so I
> assume there must be a good reason.
>

A few things will be in play;

1) A new keyword has a way of breaking old code that happens to have
used that new keyword as a name of a variable/type/etc. One of the
design philosophies of C++ has been maintaining backward compatibility
and support of existing code unless there is a significant reason not
to.

2) If an existing keyword has a name that is applicable to the new
meaning, the introduction of another keyword to support that meaning,
is either redundant or likely to cause confusion for users of the
language.

3) The auto keyword is very rarely used in practice (in places where
it can be used, it is a default attribute anyway), and scenarios
where the proposed new usage would conflict with the old will be
rare: the analysis to prevent conflict with the previous meaning will
not be prohibitive.

"Moschops" <moschops> writes:
> I note with some dismay the proposal to create a new meaning for the C and
> C++ keyword 'auto', as described in the document N1984 (part of the
> proposals for C++0X or whatever it's called now). Efforts are being taken to
>
> ensure it doesn't conflict with the previous meaning of the keyword, but why
>
> not simply have a whole new keyword? These guys aren't stupid, so I assume
> there must be a good reason.

I might be thinking about this too simply, but I'd imagine you can't
use a brand new keyword without worrying about potential collisions
with existing code, one example of which would be existing user
defined types.

I've always felt that the standards body works hard to ensure that
revisions to the standard won't break any existing standards-compliant
code. I might be off the mark on that, however.

{ Corrected the double spacing. -mod }

"Moschops" <moschops> wrote in message
news:ygqa
: I note with some dismay the proposal to create a new meaning for the C and
: C++ keyword 'auto', as described in the document N1984 (part of the
: proposals for C++0X or whatever it's called now). Efforts are being taken to
: ensure it doesn't conflict with the previous meaning of the keyword, but why
: not simply have a whole new keyword? These guys aren't stupid, so I assume
: there must be a good reason.

Given the huge existing base of C code, every newly introduced alphabetic
keyword may break many existing projects.
For an illustration of how delicate this gets:
http://www.open-std.org/jtc1/sc22/wg...006/n2105.html

New keywords have to either be uniquely cumbersome, or break existing code.
It is therefore appealing to "recycle" old keywords that have become
useless nowadays, or to overload their meaning.
[ C# took its own approach, by creating context-sensitive keywords... ]

Initially the new use of "auto" was to remain backwards-compatible
(but I'm not sure if this will hold in the end).


Regards -Ivan

Moschops wrote:
> [...]but why
>
> not simply have a whole new keyword? These guys aren't stupid, so I assume
> there must be a good reason.

keywords can not be used as identifiers, allowing this would create a
complete new class of syntactic ambiguities and make parsing a lot more
complex than it is already. Therefore any new keyword ("var","define")
potentially breaks existing code, because it is not recognized as an
identifier ("struct var;") anymore.

On Apr 24, 2:14 pm, "Moschops" <mosch> wrote:
> Posted here because comp.std.c++ seems to have died an unexpected death.
>
> -------
>
> I note with some dismay the proposal to create a new meaning for the C and
> C++ keyword 'auto', as described in the document N1984 (part of the
> proposals for C++0X or whatever it's called now). Efforts are being taken to
>
> ensure it doesn't conflict with the previous meaning of the keyword, but why
>
> not simply have a whole new keyword? These guys aren't stupid, so I assume
> there must be a good reason.

Adding a new keyword to the langauge means that you are almost
guaranteed to break someone's code. Take a look at this discussion
about var in C#:
http://www.strangelights.com/blog/ar...0/10/1264.aspx

In general, adding new meanings for an existing keyword are easier to
do without breaking old code than adding new keywords. When new
keywords are added... it generally involves searching over large code
bases for instances of the symbol already being used.

The way compilers work, true keywords are detected at lexical analysis
time (when systactic information isn't present), so you can't tell if
someone *meant* to use the keyword as a variable name, even if it is
clearly placed like this:
int var;

If var is a keyword, that will fail to parse without some fairly
heroic hackery.

So that's why languages are often pretty much stuck with the keywords
they started out with, or when they add new keywords they use ugly
prefixes that users aren't supposed to use like _. For instance in C99
they added _Imaginary, _Complex, and _Bool.

A lot of the way languages change has to do with the inflexibility of
lexers and parsers to tell that this syntax means this in a certain
context, but not in another context.

>>
>
> Yeah, nobody used auto (it was a storage class specifier that specified
> automatic storage, and since local variables are automatic by default,
> and you can't use it elsewhere, what's the point?), and so it was
> reused, to avoid adding new keywords. If you add new keywords, you risk
> breaking existing code.
>

Perhaps next language we should have a symbol that identifies keywords, to
save us having to overload already existing keywords. Some kind of prefix
that's illegal to use unless it is prefixing a recognised keyword.

'Chops

Bob ha scritto:
>
> 3) The auto keyword is very rarely used in practice (in places where
> it can be used, it is a default attribute anyway), and scenarios
> where the proposed new usage would conflict with the old will be
> rare: the analysis to prevent conflict with the previous meaning will
> not be prohibitive.
>

Please notice that since the latest draft, the auto keyword can no
longer be used with the old meaning. It can only be used with the new
meaning. The old meaning was exceedingly rarely used so, for sake of
clarity and simplicity, it was decided to remove it entirely without
even a "deprecation" period.

Ganesh

On 2008-04-25 00:13:19 -0400, "Ivan Vecerina"
<_INVALID_use_webform_> said:

>
> Initially the new use of "auto" was to remain backwards-compatible
> (but I'm not sure if this will hold in the end).
>

It didn't hold. The old usage of "auto" is not supported in C++0x.

red floyd wrote:

>
> Yeah, nobody used auto (it was a storage class specifier that specified
> automatic storage, and since local variables are automatic by default,
> and you can't use it elsewhere, what's the point?), and so it was
> reused, to avoid adding new keywords. If you add new keywords, you risk
> breaking existing code.
>
At least they didn't overload another definition for static.

On Apr 25, 12:47 pm, "Moschops" <mosch> wrote:
>>
>
> Perhaps next language we should have a symbol that identifies keywords, to
> save us having to overload already existing keywords. Some kind of prefix
> that's illegal to use unless it is prefixing a recognised keyword.
>
> 'Chops

Which is again would be a keyword? I would hate to implement such
grammar :)

Brendan wrote:

> [...]
> Adding a new keyword to the langauge means that you are almost
> guaranteed to break someone's code. Take a look at this discussion
> about var in C#:
> [..]

The de-facto standard naming convention of C# forbids to start a class
name with a lower case char. Since all keywords start with a lower case
char, it's rather unlikely that code is broken if a new context
sensitive keyword is introduced in C#. Of course nobody is forced to use
this naming convention (besides that some QC tools warn if this
convention isn't used), but then the developer has to take the risk of
collisions in future C# versions.

> [...]
> The way compilers work, true keywords are detected at lexical analysis

Typically C++ compilers. But there are other compilers, like C# and some
C++ compilers too, which IMHO simply can't detect all keywords at
lexical analysis stage, because they support (proprietary) context
sensitive keywords.

> [...]
>
> A lot of the way languages change has to do with the inflexibility of
> lexers and parsers to tell that this syntax means this in a certain
> context, but not in another context.

Well, there are good reasons that keywords must be able to be detected
by the lexer, so that simple tools e.g. colorizing the keywords can be
implemented quite easy and to significantly reduce the complexity of the
parser / semantic stage.

But anyways IMHO it's not always the best solution, regarding code
efficiency and complexity, to prefer new library code over new keywords.
Regarding downwards compatibility and for compiler implementors it's
surely the better solution.

Andre

On Apr 25, 3:13 pm, nickf3 <nic> wrote:
> On Apr 25, 12:47 pm, "Moschops" <mosch> wrote:
>>
>> Which is again would be a keyword? I would hate to implement such
> grammar :)

He said a prefix. C99, and also compiler writers already do this by
prefixing extensions with _ or __. Like _Complex. While the compiler
will not stop you from using _ or __ prefixes in your code, they are
reserved for implementation by convention (it's in the standard
somewhere I think).

Thus, there is a way to add new keywords to C and C++ without breaking
anything... but they are ugly keywords because they all start with _.
Thus, the standards committee has chosen to risk breaking code by
adding new keywords without underscores a number of times.

I think a better idea than designing a language with a prefix for
keywords, is designing a language with a prefix for variables. Many
languages use sigils such as $, @, @@ to prefix variables and
disambiguate scope. Additonally, ruby uses upper an upper case first
letter to identify constants and types. If you made this universal,
you could have a grammar with a syntax that could be arbitrarily
extended without risking breaking old code. You could also use
keywords for variable names, because the lexer would be able to tell
the difference with a simple regular expression. You could have the
keyword auto and the variable $auto.

Unfortunately, neither C++ nor any other language I know of has taken
that path, and thus extending the syntax becomes painful.

Brendan Miller

On 25 Apr, 22:39, Ron Natalie <r> wrote:
> red floyd wrote:
>
> > Yeah, nobody used auto (it was a storage class specifier that specified
> > automatic storage, and since local variables are automatic by default,
> > and you can't use it elsewhere, what's the point?), and so it was
> > reused, to avoid adding new keywords. If you add new keywords, you risk
> > breaking existing code.
>
> At least they didn't overload another definition for static.

Yes, thank goodness. But I reckon a time will come when they do. IMO
the desire to avoid introducing new keywords is too great, to the
point where it is against common sense. We are lucky that in practice
auto can be safely used as if it was a new keyword (since no-one uses
it). Next time we may not be so lucky.

I understand the theory that new keywords may break existing code but
really, I think this is not a big deal, provided that the keyword is
not a very common word. I have seen more problems with third-party
headers defining macros in lowercase that are common words. These
clash wth identifiers chosen by programmers that have to use these
third-party headers on their projects. The most common case I have
seen of a keyword clashing is when a C header has to be used in C++
code and the C header has identifiers called 'class'. Every now and
then I still come across this. I think it is far more likely than a
class that would be caused by introducing a new keyword.

-Andrew Marlow