Removal of the __ Keyword Prefix

What s Different in the Revised Language Definition?

Removal of the  __ Keyword

One general transformation of the language between
the original and revised language design is the removal of the double-underscore from
all keywords. For example, a property is now declared as property, not __property,
and so on.

Why Did We
Originally Use the `__ Syntax?

There were two primary reasons for using the double-underscore
prefix in the original language design:

  1. It is the conformant method of providing local extensions
    to the ISO C++ Standard. A primary goal of the original language design was to not
    introduce incompatibilities with the standard language, such as new keywords and tokens.
    It was this reason, in large part, that motivated the choice
    of pointer syntax for the declaration of objects of managed reference types.

  1. The use of the double-underscore, apart from its
    conformant aspect, is also a reasonable guarantee of being non-invasive with the existing
    code base of our users. This was a second primary goal of the original language design.

Why Did We
Remove the `__ Syntax?

Why, then, did we remove the double-underscore (as
well as introduce a number of new tokens)? Are we no longer concerned with being conformant
with the standard?

No, we remain committed to being conformant. However,
we recognize that support for the .NET dynamic object model represents a new and powerful
programming paradigm.

Both our experience with the original language design
and our experience with the design and evolution of the C++ language itself have convinced
us that support of this new paradigm requires its own high-level keywords and tokens.

We have sought to provide a first-class expression
of this new paradigm while integrating it and supporting the standard language. We
hope you agree that the revised language design provides a first class programming
experience of these two disparate object models. 

Contextual and Spaced Keywords
Provide the Solution.

We remain very concerned with maximizing the non-invasive
nature of these new language keywords. This has been accomplished the use of contextual and spaced keywords.
Before we look at the actual revised language syntax, let s try to make sense of
these two special keyword flavors.

What is a
Contextual Keyword?

A contextual keyword has a special meaning on within
specific program contexts. Within the general program, for example,
sealed is
treated as an ordinary identifier. However, when it occurs within the declaration
portion of a managed reference class type, it is treated as a keyword within the context of
that class declaration.

This minimizes the potential invasive impact of introducing
a new keyword in the language, something that we feel is very important to users with
an existing code base. At the same time, it allows users of the new functionality
to have a first-class experience of the additional language feature something we
felt was missing from the original language design.

What is a
Spaced Keyword?

A spaced keyword is a special case of a contextual
keyword. It literally pairs an existing keyword with a contextual modifier separated
by a space. The pair is treated as a single unit, such as
, rather than as two separate keywords.

In practical terms, this means that a macro redefinition
such as the following, 

            #ifndef __cplusplus_cli


does not
blank out
value from
a class declaration. If one should wish to accomplish this, one would have to redefine
the unit pair by writing

            #ifndef __cplusplus_cli

value class class

While this behavior under the preprocessor can lead
to surprises, these surprises are limited to the use of the preprocessor, and for
those of us unsympathetic to the preprocessor in general, that doesn t seem overwhelming
concern, although it does upset those that remain loyal to its uses. The preprocessor
is an over 30-years old technology, and I would much prefer seeing a modern day language-sensitive

This posting is provided "AS IS" with no warranties, and confers no rights. 



Comments (4)

  1. AlisdairM says:

    __keywords are ceratinly unpleasant to use, and often avoided just because they are ugly and hit you over the head that you are using an extension. Of course, there is the argument that ISO recommend it is done like this for precisely this reason <g>
    I find the context-sensitive keyword an interest workaround for the issue, and am fairly glad I am not the compiler writer trying to support this! Full marks for trying to find the most elegant compromise.

    I am still not convinced that all the proposed keywords are needed (eg for each) but that is a matter of decided where to draw the line between providing a path for C++ to work under .NET and providing a new language with entirely new facilities that is a superset of C++. for each is certainly not need to work in .NET land (Oz?!) but it might be quite convenient.

    I am still in the ‘as close to C++ as possible’ camp, and am yet to be convinced that some of these extensions fall under the ‘but no closer’ exemption. After all, if I want to write C#, the CLI binding will let me mix C# and C++ code almost at will, and that is A Good Thing.

  2. stan lippman says:

    You are not the first person to suggest that for each is unnecessary, while the functionality it provides is to be desired, and it looks as if that may happen in the course of the ECMA standardization — watch Herb Sutter and Brandon Bray’s blogs for details.

    No one is convinced that all the keywords are necessary — but that was the case with C++ as well. Perhaps you remember overload? Perhaps you do not champion explicit., or the new-fangled cast keywords 🙂

    Again, when someone says to me, as close to C++ as possible, I always bring up the introduction of the class keyword. This is not a necessary keyword … You have to remember that while Andy Koenig’s phase, "as close to C as possible, but no closer" is elegant, it is not a reflection of how C++ really developed, and so it is perhaps not a fair measure to put C++/CLI against. Of course, let me hasten to say, these are my own ill-considered opinions.

Skip to main content