kuyper@wizard.net ("James Russell Kuyper Jr.") wrote:
>
>A feature doesn't deserve standardization until it's so widespread that
>it's no longer considered innovative.

Agreed.

"Gennaro Prota" <gennaro_prota@yahoo.com> wrote...
> So, please, can you tell me what are these so widespread features that
> will be considered for C++0x standardization?

I can't think of any. If we were forced to produce a new C++ standard
tomorrow, I expect it would read exactly the same as the current one,
give or take a few defects that have already been addressed.

In practice, however, we have a fair number of years to invent.


---
[ 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 Sat, 28 Sep 2002 21:47:03 +0000 (UTC), kuyper@wizard.net ("James
Russell Kuyper Jr.") wrote:

>A feature doesn't deserve standardization until it's so widespread that
>it's no longer considered innovative.

So, please, can you tell me what are these so widespread features that
will be considered for C++0x standardization?


Genny.

---
[ 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                       ]

kanze@gabi-soft.de (James Kanze) wrote in message news:<d6651fb6.0209230546.792edf33@posting.google.com>...
> gennaro_prota@yahoo.com (Gennaro Prota) wrote in message
> news:<58vgousovvsbasa38aqhkvblm1oeep3erg@4ax.com>...

> With regards to Koenig lookup, in retrospect, the problem was
> namespaces.  I think it is obvious, in retrospect, that adopting
> namespaces without any real existing practice was a mistake.  Koenig
> lookup is an effort to make that mistake bearable.  (And extending it to
> template instantiations is an effort to confuse anyone who had ever used
> templates before:-).)

Actually, the problem wasn't so much lack of existing practice as lack
of familiarity within the committee with the existing practice.
Lucent had bolted on namespaces to their C compiler long before 98.

They were rather unlike the current C++ namespaces, but served
pretty much the same goal w.r.t. to name clashes. In addition they
supported encapsulation (for which C++ uses private class members).

Regards,
--
Michiel Salters

---
[ 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                       ]

Allan W wrote:
[snip]
> Besides DRs, there has been a lot of discussion for proposed new
> features. Well, this certainly is the right newsgroup for that!
> However, it seems like every single proposal that I see -- whether
> I personally love it or hate it -- meets with almost exactly the
> same objections, to some degree or another.
[snip]

   I have been thinking for months about a related topic:  the vast majority of
new ideas discussed in this forum are thoroughly torn to shreds by others in
this forum.  I have what I think to be a non-purjorative explanation if the
reader hears me out below.


   On many topics in any widespread group of people, there is a fundamental
difference of viewpoint between conservation/defensiveness of the status quo
versus progressiveness for change.  The C++ community (and the C++
standardization participants) must ask themselves just how much the priority is
on defending the status quo of C++98 versus progressiveness (into improving
C++'s expressiveness in the C++98-supported paradigms of POP, OOP, GP, and a tad
of XAOP or into expanding C++'s expressiveness into new paradigms beyond C++98:
Haskell-like functional programming, reflection, higher math).

   This difference of viewpoint occurs at the larger social level of
national/municipal government as well as in C++ standardization.  In fact
ISO/ANSI standards bodies substantially play the role of government on a
per-cohesive-technical-topic (e.g., C++) basis.  Whether we individually admit
it or not, there are in fact partisan roles which are played in any government
(either general-society government or standardization bodies) which form a sort
of coordinate system.  [Note that "positive" and "negative" are used in their
Cartesian/mathematical sense, not in the negative=retrograde sense.]

   conservative/preservative [positive x-axis, negative y-axis]:
   Keep it the same as it currently is: no more, no less.  Enforce the laws
[standards content] already on the books.  Each individual is responsible for
their own actions or else they fall without safety net.

   liberal [negative x-axis, positive y-axis]:
   Enact a generous set of laws [standards content] guaranteeing an
ever-expanding set of new freedoms.  Do not impede the expressivity of any
citizen [programmer].

   libertarian [negative x-axis, negative y-axis]:
   Roll back to an extremely minimalistic set of laws [standards content].  Do
not impede the expressivity of any citizen [programmer] with new
restrictions/laws [standards content].  Do not burden the law enforcement
[compiler writers] with excessive laws to enforce.

   communitarian/social-engineering [positive x-axis, positive y-axis]:
   Enact a generous set of laws [standards content] establishing cattle-chutes
to marshall a society [all C++ programmers] to go in the same direction to reach
some (hopefully desirable) goal, so that the society has little other choice
apart from dropping out of the society.  Each individual is responsible for
their own actions or else they suffer the penalty of bumping into the
sternly-imposed cattle-chutes.


   I claim that C++ standardization follows conservative/preservative &
libertarian trends.  I claim that many of the proposed new ideas tend to fall
into the liberal & communitarian categories and thus are held in disdain by the
prevailing conservatives/preservatives & libertarians.  There is a natural
polarity.  There is a natural 4-way tug of war among the aforementioned 4
directions in the coordinate system which then tends to align over time into a
natural 2-way tug of war: conservatives aligning with libertarians (as
proponents of smaller government) and liberals aligning with communitarians (as
progressives).  Although on a few microscopic topics the other alignment occurs:
  liberals aligning with libertarians (as defenders of freedom) and
conservatives/preservatives aligning with communitarians/social-engineers (as
defenders of existing practices which lead to betterment).  All of this is the
fundamental nature of bodies politic which recurs ad infinitum, including in
standardiation bodies.  Standardization is primarily a political process of a
democracy of people.

   (Which of the 4 categories of politics is the best one is left as an exercise
for the reader.  Whether C++ standardization should be harshly preserving of
C++98 at one extreme or should be radically progressive at the other extreme or
some hybrid in between is also left as an exercise for the reader.  And for the
progressives, whether C++ progressiveness should occur within C++0x or in a new
separate post-C++ language is left to the progressive reader.)


   [ GLOSSARY ]

   POP = procedure-oriented programming
   OOP = object-oriented programming
   GP = generic programming
   XAOP = transaction-oriented programming (supported in part by exceptions as a
transaction abortion mechanism)

---
[ 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                       ]

Dan'l Miller wrote:
>
> Allan W wrote:
> [snip]
> > Besides DRs, there has been a lot of discussion for proposed new
> > features. Well, this certainly is the right newsgroup for that!
> > However, it seems like every single proposal that I see -- whether
> > I personally love it or hate it -- meets with almost exactly the
> > same objections, to some degree or another.
> [snip]
>
>    I have been thinking for months about a related topic:  the vast majority of
> new ideas discussed in this forum are thoroughly torn to shreds by others in
> this forum.  I have what I think to be a non-purjorative explanation if the
> reader hears me out below.
>
>    On many topics in any widespread group of people, there is a fundamental
> difference of viewpoint between conservation/defensiveness of the status quo
> versus progressiveness for change.  The C++ community (and the C++
> standardization participants) must ask themselves just how much the priority is
> on defending the status quo of C++98 versus progressiveness (into improving
> C++'s expressiveness in the C++98-supported paradigms of POP, OOP, GP, and a tad
> of XAOP or into expanding C++'s expressiveness into new paradigms beyond C++98:
> Haskell-like functional programming, reflection, higher math).

There also seems to be widespread misunderstanding of the role that the
standard plays. Many people think that the standard should be where
innovations start. That's entirely contrary to the purpose of
standardization. The standard is the place where innovations END. A
feature doesn't deserve standardization until it's so widespread that
it's no longer considered innovative. That misunderstanding hasn't been
helped much by the fact that C++98 violated this principle badly.

Standardization is like cryonics: once something is standardized, it's
almost impossible to make any further significant changes to it. Given
the current state of the art, you certainly wouldn't want to freeze
someone's body until you're sure that freezing them couldn't possibly
make things any worse (i.e., they're already dead).  Similarly, you
should be careful not to standardize something until you're as sure as
you can be that it won't need any further changes.

---
[ 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                       ]

In article <d6651fb6.0209230546.792edf33@posting.google.com>, James
Kanze <kanze@gabi-soft.de> writes
>> More than often, proposal are appraised proportionally to the
>> authority of the author.
>
>No author got his way for everything, and I know that some proposals by
>Stroustrup were voted down.  On the other hand, it is sure that it helps
>if the author is there at the meetings to answer questions, etc.

It also helps if the author is known to be likely to understand the
issues. It is easy to come up with a bright idea in isolation, but they
have to be implemented in an already complicated situation.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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                       ]

gennaro_prota@yahoo.com (Gennaro Prota) wrote in message
news:<58vgousovvsbasa38aqhkvblm1oeep3erg@4ax.com>...

    [...]

> Actually I think everybody here should be fair enough to admit that
> these rules are everything but 'rules', and they are often used as an
> excuse to reject ideas on an opinion basis. Who implemented 'export'
> before it was standardized? Who Koenig lookup correctly? As to
> experiencing new features: what about exception specifications?

I think you have to distinguish between fixing things that are broken,
and introducing new features.  Early implementations of templates DIDN'T
require source code to compile.  They had there problems, and in the
end, it isn't only export where the standard innovated, but the entire
chapter 14.  While I sometimes think that there was too much innovation
in this case, it is important to realize that there were two
incompatible existing practices for the standard to consider -- when the
C committee was faced with a similar problem with regards to the
preprocessor, they also created something entirely new.

With regards to Koenig lookup, in retrospect, the problem was
namespaces.  I think it is obvious, in retrospect, that adopting
namespaces without any real existing practice was a mistake.  Koenig
lookup is an effort to make that mistake bearable.  (And extending it to
template instantiations is an effort to confuse anyone who had ever used
templates before:-).)

> More than often, proposal are appraised proportionally to the
> authority of the author.

No author got his way for everything, and I know that some proposals by
Stroustrup were voted down.  On the other hand, it is sure that it helps
if the author is there at the meetings to answer questions, etc.

> Think for instance to what reaction it would have arisen if someone
> had proposed here to allow implicit void*->pointer-to-object
> conversion. Or e.g. to introduce a wchar keyword.

> You might also want to have a look at this:

>   http://aspn.activestate.com/ASPN/Mail/Message/1362369

> Add the fact that who proposes an idea here will presumably not be
> present to defend it when it will be discussed and you will easily
> conclude that -de facto- nobody can really hope to get something into
> the standard without becoming a member.

First, of course: if you really want something, why not become a member.

It is certain that nothing will be voted on in this group.  ISO doesn't
allow it.  That doesn't mean that the group has no role.  But if the
discussions in the group lead to a certain consensus that some new
feature is needed, at some point, it becomes necessary to make a formal
proposition and to be ready to defend it.  And an article in this group
is NOT a formal proposition.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

Gennaro Prota wrote:
>
> On Wed, 18 Sep 2002 04:28:05 +0000 (UTC), kuyper@wizard.net ("James
> Russell Kuyper Jr.") wrote:
....
> >No. But the non-compiler writers who make those suggestions should be
> >making them to compiler writers, not standardizers. Those compiler
> >writers should make the first implementations of the new feature. A fair
> >number of people should have a fair amount of experience with actually
> >using the new feature long before anyone bothers asking whether or not
> >it should be standardized.
>
> Actually I think everybody here should be fair enough to admit that
> these rules are everything but 'rules', and they are often used as an
> excuse to reject ideas on an opinion basis. Who implemented 'export'
> before it was standardized? Who Koenig lookup correctly? As to
> experiencing new features: what about exception specifications?

IMHO the language would have been better off if standardization of those
features had waited upon actual implementation experience. In
particular, 'export' seems to have been much more complicated to
implement than it's proposers probably expected it to be. The fact that
the certain principles have been ignored in the past doesn't mean that
it was a good idea to ignore them.

> More than often, proposal are appraised proportionally to the
> authority of the author. ...

That sounds reasonable to me. If someone is known to have the relevant
skills and experience to judge whether something is a good idea, that's
a legitimate reason to pay closer attention to that person's arguments
for that opinion. Of course, the arguments still have to actually make
sense, regardless of the author.

---
[ 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                       ]

Allan W wrote:
>
> The FAQ states that the easiest way to submit a potential Defect Report
> is to submit it right here; "The moderators of [this] newsgroup have
> agreed to act as a preliminary filter, and forward reasonable-looking
> DRs to the C++ Committee for consideration." This is great.
>
> Besides DRs, there has been a lot of discussion for proposed new
> features. Well, this certainly is the right newsgroup for that!
> However, it seems like every single proposal that I see -- whether
> I personally love it or hate it -- meets with almost exactly the
> same objections, to some degree or another.
>
>     * We don't want to add new keywords, if possible.
>     * No point in adding a feature to the language to support something
>       that we can already do.
>     * Don't break existing code -- even if it's contrived code and we
>       have no knowledge of anyone doing this in real life.
>     * Make sure that it really is implementable -- and has zero overhead
>       for programs that do NOT use it.
>     * Whenever possible, make sure that it's been implemented somewhere
>       so that we can talk about how well it worked -- preferably as a
>       non-standard extension to some C++ compiler, but other language
>       experience might also be helpful.
>
> The funny thing is, I support every one of these rules, at least in
> isolation. But it occurs to me that if neither C nor C++ already had
> the "for" statement, and someone proposed it here, it would be shot
> down at once.
....
> I would suggest a small addition to the FAQ (with appropriate
> announcements here in the newsgroup), stating recommended guidelines
> for new features. In particular, I would recommend answering questions
> such as these:
>
>     * Exactly how much do we hate new keywords? Does it automatically
>       make any new proposal unlikely to succeed?

New keywords are to be avoided, but not absolutely prohibited. However,
it's almost always possible to avoid them.

>     * Related but slightly different from above: if the feature breaks
>       code from the "obfuscated C++ contest", but little or no "real
>       world" code -- how much do we care?

If it breaks "no real world code", not at all. The far more common case
is that it breaks "little real world code", where "little" is a highly
debateable judgement influenced mainly by the limited experience of the
person proposing the change.

>     * Is it really possible to know that a new feature breaks little or
>       no "real world" code?

Not in general. As a general rule, any feature that can be used, has
been used, and probably has been used far more often than you think is
likely.

>     * If something can already be done manually, which of the following
>       (in roughly what order) are required and/or helpful to make the
>       new proposal likely to succeed anyway?
>        [_] Easier to type
>        [_] Less error-prone
>        [_] Less surprising to new users
>        [_] Less surprising to experienced users
>        [_] Easier to debug
>        [_] Similar to tried and true features from other languages
>        [_] Likely that good compilers could optimize better
>        [_] Easier to produce in code generators
>        [_] Easier to parse in non-compiler language tools
>        [_] Compatibile with C
>        [_] Compatibile with APL / PDP-11 assembly / EBCDIC characters /
>            UNICODE characters / Morse Code / other computer languages

All of those are helpful, none of them are necessary, and all of them
combined are not necessarily sufficient.

>     * Even the best programmers sometimes fail to recognize
>       implementation details until late in the process. What's the
>       best way to assure ourselves that a proposal *probably* doesn't
>       introduce overhead when the feature is not used?

By implementing it as an extension to an existing implementation. By not
standardizing it until it's actually been implemented, so that "late in
the process" has already happened BEFORE you even start considering the
question of whether it should be standardized.

>     * We can't really *know* for a fact that a feature is implementable
>       until someone has implemented it. Does that mean that only compiler
>       writers should be making language suggestions?

No. But the non-compiler writers who make those suggestions should be
making them to compiler writers, not standardizers. Those compiler
writers should make the first implementations of the new feature. A fair
number of people should have a fair amount of experience with actually
using the new feature long before anyone bothers asking whether or not
it should be standardized.

---
[ 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 Wed, 18 Sep 2002 04:28:05 +0000 (UTC), kuyper@wizard.net ("James
Russell Kuyper Jr.") wrote:

>Allan W wrote:
>>
>> The FAQ states that the easiest way to submit a potential Defect Report
>> is to submit it right here; "The moderators of [this] newsgroup have
>> agreed to act as a preliminary filter, and forward reasonable-looking
>> DRs to the C++ Committee for consideration." This is great.
>>
>> Besides DRs, there has been a lot of discussion for proposed new
>> features. Well, this certainly is the right newsgroup for that!
>> However, it seems like every single proposal that I see -- whether
>> I personally love it or hate it -- meets with almost exactly the
>> same objections, to some degree or another.
>>
>>     * We don't want to add new keywords, if possible.
>>     * No point in adding a feature to the language to support something
>>       that we can already do.
>>     * Don't break existing code -- even if it's contrived code and we
>>       have no knowledge of anyone doing this in real life.
>>     * Make sure that it really is implementable -- and has zero overhead
>>       for programs that do NOT use it.
>>     * Whenever possible, make sure that it's been implemented somewhere
>>       so that we can talk about how well it worked -- preferably as a
>>       non-standard extension to some C++ compiler, but other language
>>       experience might also be helpful.
>>
>> The funny thing is, I support every one of these rules, at least in
>> isolation. But it occurs to me that if neither C nor C++ already had
>> the "for" statement, and someone proposed it here, it would be shot
>> down at once.
>....
>> I would suggest a small addition to the FAQ (with appropriate
>> announcements here in the newsgroup), stating recommended guidelines
>> for new features. In particular, I would recommend answering questions
>> such as these:
>>
>>     * Exactly how much do we hate new keywords? Does it automatically
>>       make any new proposal unlikely to succeed?

I think there's no answer. It's based on the opinion of the people who
will vote the proposal.

>New keywords are to be avoided, but not absolutely prohibited. However,
>it's almost always possible to avoid them.

Yes. And then someone objects that the invented syntax is too similar
to something else. For instance

class A {
 A (const A&) = 0; // or '= not'
};

to prohibit the definition of the copy constructor being too similar
to the syntax of pure virtual functions (despite the absence of
'virtual').

>
>>     * Related but slightly different from above: if the feature breaks
>>       code from the "obfuscated C++ contest", but little or no "real
>>       world" code -- how much do we care?
>
>If it breaks "no real world code", not at all. The far more common case
>is that it breaks "little real world code", where "little" is a highly
>debateable judgement influenced mainly by the limited experience of the
>person proposing the change.

Actually, when it comes to new keywords it's not a matter of
experience. The identifier 'could' have been used as a variable or
function name, but no expert in the world can say you how much it's
used, unless he knows the set U of all the C++ code written in the
world.

[...]
>>     * Even the best programmers sometimes fail to recognize
>>       implementation details until late in the process. What's the
>>       best way to assure ourselves that a proposal *probably* doesn't
>>       introduce overhead when the feature is not used?
>
>By implementing it as an extension to an existing implementation. By not
>standardizing it until it's actually been implemented, so that "late in
>the process" has already happened BEFORE you even start considering the
>question of whether it should be standardized.
>
>>     * We can't really *know* for a fact that a feature is implementable
>>       until someone has implemented it. Does that mean that only compiler
>>       writers should be making language suggestions?
>
>No. But the non-compiler writers who make those suggestions should be
>making them to compiler writers, not standardizers. Those compiler
>writers should make the first implementations of the new feature. A fair
>number of people should have a fair amount of experience with actually
>using the new feature long before anyone bothers asking whether or not
>it should be standardized.

Actually I think everybody here should be fair enough to admit that
these rules are everything but 'rules', and they are often used as an
excuse to reject ideas on an opinion basis. Who implemented 'export'
before it was standardized? Who Koenig lookup correctly? As to
experiencing new features: what about exception specifications?

More than often, proposal are appraised proportionally to the
authority of the author. Think for instance to what reaction it would
have arisen if someone had proposed here to allow implicit
void*->pointer-to-object conversion. Or e.g. to introduce a wchar
keyword.

You might also want to have a look at this:

  http://aspn.activestate.com/ASPN/Mail/Message/1362369


Add the fact that who proposes an idea here will presumably not be
present to defend it when it will be discussed and you will easily
conclude that -de facto- nobody can really hope to get something into
the standard without becoming a member.

Genny.

---
[ 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 Wed, 18 Sep 2002 02:06:33 +0300, Allan W wrote:



>     * If something can already be done manually, which of the following
>       (in roughly what order) are required and/or helpful to make the
>       new proposal likely to succeed anyway?
>        [_] Easier to type
>        [_] Less error-prone
>        [_] Less surprising to new users
>        [_] Less surprising to experienced users [_] Easier to debug [_]
>        Similar to tried and true features from other languages [_]
>        Likely that good compilers could optimize better [_] Easier to
>        produce in code generators [_] Easier to parse in non-compiler
>        language tools [_] Compatibile with C [_] Compatibile with APL /
>        PDP-11 assembly / EBCDIC characters /
>            UNICODE characters / Morse Code / other computer languages

IMO the important property for something that could be done manualy is
that it expresses a unique logical part of the program design, I don't
think the amount of typing involved is as important as the giving space
to think in terms of a higher level structure.

for instance the argument for the for loop would be:
although we can achieve the same  effect with a while loop having both
kinds will be very useful because it allows the programmer to distinguish
between two kinds of loops, loops where the number of iterations is known
before entering the loop (ie the loop control depends on factors external
to the loop) as in  for  loops, and loops where the number of iterations
is unknown before entering the loop (control depends on factors from
within the loop) like while loops.

admitedly you can achieve both effect with a while or a for loop, but
this probably only means that the syntax for the for loop would have been
slightly different.

cheers,
Alaa

---
[ 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                       ]

The FAQ states that the easiest way to submit a potential Defect Report
is to submit it right here; "The moderators of [this] newsgroup have
agreed to act as a preliminary filter, and forward reasonable-looking
DRs to the C++ Committee for consideration." This is great.

Besides DRs, there has been a lot of discussion for proposed new
features. Well, this certainly is the right newsgroup for that!
However, it seems like every single proposal that I see -- whether
I personally love it or hate it -- meets with almost exactly the
same objections, to some degree or another.

    * We don't want to add new keywords, if possible.
    * No point in adding a feature to the language to support something
      that we can already do.
    * Don't break existing code -- even if it's contrived code and we
      have no knowledge of anyone doing this in real life.
    * Make sure that it really is implementable -- and has zero overhead
      for programs that do NOT use it.
    * Whenever possible, make sure that it's been implemented somewhere
      so that we can talk about how well it worked -- preferably as a
      non-standard extension to some C++ compiler, but other language
      experience might also be helpful.

The funny thing is, I support every one of these rules, at least in
isolation. But it occurs to me that if neither C nor C++ already had
the "for" statement, and someone proposed it here, it would be shot
down at once.

    * I've used 'for' in Pascal and Basic, but the syntax and semantics
      are completely different -- this new way simply won't work
    * We can already do the equivalent with while, do/while, or even
      if/goto -- no need to complicate the language further.
    * Since the statement and all three expressions are optional, this
      statement could maliciously or even accidentally be misused.
    * Shouldn't there be a semicolen after the right-paren, before the
      compound statement?
    * Shouldn't we ban semicolens after the right-paren, before the
      compound statement?
    * Stroustrup would have liked this, see his website and the
      overloaded whitespace proposal
    * Stroustrup never meant for any such thing, see D&E

I would suggest a small addition to the FAQ (with appropriate
announcements here in the newsgroup), stating recommended guidelines
for new features. In particular, I would recommend answering questions
such as these:

    * Exactly how much do we hate new keywords? Does it automatically
      make any new proposal unlikely to succeed?
    * Related but slightly different from above: if the feature breaks
      code from the "obfuscated C++ contest", but little or no "real
      world" code -- how much do we care?
    * Is it really possible to know that a new feature breaks little or
      no "real world" code?
    * If something can already be done manually, which of the following
      (in roughly what order) are required and/or helpful to make the
      new proposal likely to succeed anyway?
       [_] Easier to type
       [_] Less error-prone
       [_] Less surprising to new users
       [_] Less surprising to experienced users
       [_] Easier to debug
       [_] Similar to tried and true features from other languages
       [_] Likely that good compilers could optimize better
       [_] Easier to produce in code generators
       [_] Easier to parse in non-compiler language tools
       [_] Compatibile with C
       [_] Compatibile with APL / PDP-11 assembly / EBCDIC characters /
           UNICODE characters / Morse Code / other computer languages
    * Even the best programmers sometimes fail to recognize
      implementation details until late in the process. What's the
      best way to assure ourselves that a proposal *probably* doesn't
      introduce overhead when the feature is not used?
    * We can't really *know* for a fact that a feature is implementable
      until someone has implemented it. Does that mean that only compiler
      writers should be making language suggestions?

I want to thank the moderators and the C++ standardization committee for
cooperating so well (sometimes by being the same people!). As far as I
know, no other language standardization effort gets this level of input
from the users of that language. You can't possibly implement every
suggestion made here, nor would you want to; however, I think that
everyone who makes a proposal at least feels that their views have been
heard and considered!

---
[ 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                       ]