There's a general reluctance to introducing new keywords into
C++.  This is resulting in convoluted syntax and overloading of
keywords, as desperate attempts are made to avoid introducing
new keywords.

    I suggest that new keywords be used when indicated, but
such keywords would only have their keyword meaning if

 using "keyword";

appears in the compilation unit.

This would allow language improvement without backwards
compatibility problems.

    John Nagle
    Animats

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-08-05 18:00, John Nagle wrote:
:
>     I suggest that new keywords be used when indicated, but
> such keywords would only have their keyword meaning if
>
>  using "keyword";
>
> appears in the compilation unit.
>
> This would allow language improvement without backwards
> compatibility problems.

Using it in header files would cause backward compatibility problems
for code that includes these headers.

Anyway, there already exists a well-established idiom that provides an
equivalent yet more flexible functionality: Use a reserved name for
the new keyword (e.g. "_Keyword"), and define a macro when a less
unsightly identifier is desired (e.g. "#define keyword _Keyword").
This is how C99 introduced "bool", "complex" and "imaginary".

-- Niklas Matthies

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> writes:

>    I suggest that new keywords be used when indicated, but
> such keywords would only have their keyword meaning if
>
>  using "keyword";
>
> appears in the compilation unit.
>
> This would allow language improvement without backwards
> compatibility problems.

If it isn't limited to the scope in which it appears, you'll have
interoperability problems between old and new code.  This approach is
almost Pythonic; they use

    from __future__ import feature;

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]