🚀 go-pugleaf

If I were to post this message to one of the x3j16 mailing lists,
I would just get *everybody* on x3j16 pissed off at me.  So instead
of doing that, I'll just post it here.  That way I can just get
the *subset* of the x3j16 membership that reads this newsgroup
pissed-off at me. (1/2 :-)

For those of you who are reading this who are not members of x3j16,
you should know that x3j16 is organized into a set of "working groups",
each of which is attempting to address outstanding issues and questions
relating to some particular aspect of the language.  For example, there
is the "core language" working group, the "library" working group,
the "environment" working group, and the "extensions" working group.

The "extensions" working group has been tasked with dealing with all
of the various "bright ideas" that have cropped up (and which continue
to crop up) for new whiz-bang additions to the language (as currently
defined by the draft standard document, which is still pretty close to
the ARM).

It has just occured to me that there exists some built-in bias in the
set of existing working groups for x3j16.  In particular, it does seem
to be a bit loopsided to have an "extensions" working group without
also having a complimentary "contractions" working group, where people
who are worried about the "excess baggage" which is already in the
language could take their concerns and have them properly aired.

Now I know that comp.std.c++ is *not* the proper forum in which to
formally propose that such a working group be formed (this sort of
thing has to be taken to the committee directly) but that's perfectly
alright because I'm not *seriously* proposing the formation of such
a working group anyway.  Rather, I'm just making an observation (in
an indirect sort of way) about the way the C++ standardization effort
seems to be going.  (In all fairness, it seems that perhaps *all*
standardization efforts go this way.)

People always assume that once you convene a standardization committee
that the only thing that can (or should) happen from then on is that
new "features" will be added, and that no existing "features" (however
ill-conceived) will be subtracted.

I'll bet that if we picked 100 readers of this newsgroup and asked them
how they would like to see the language change as it goes from the ARM
to and ANSI standard, 99 out of 100 people will start to tell you all about
their own pet ideas for *additions* to the language.  Few (if any) will
talk about the things they would like to see removed.

My observation about these trends and tendencies: "It's a shame".

Why (you may ask) is rfg going on and on about these things?

Well, quite simply, I realized that there were a few things which I
honestly feel should be "disappeared" from the language.  I have a
sad feeling that there is no way on God's green earth that *anything*
actually *will* be disappeared from the language (from this point
forward) regardless of the merits (or lack thereof).  That realization
makes me a bit irritable, and I'm just venting my frustration here
(where hopefully it won't hurt anybody or anything).

The best example of what I'm talking about (and the only one I'm prepared
to give at the moment) is implicit applications of user-defined type
conversions.  These are (in my opinion) analogous to the "forbidden
fruit" in the Garden of Eden.  Many people find them quite tasty, but
that doesn't mean that they are good for you.  Quite the opposite.
They can cause tooth decay (if not to say hair loss) for software
*maintainers*.

Bjarne had a feature in the language for awhile called "delegation".  He
finally yanked it out and later wrote that delegation was "the GOTO of
data structures".  I really have to give him credit for this powerful
analogy.  I doubt that he ever again had to defend his decision to
yank delegation from the language.  After all, in this enlightened age,
most language laywers (and others who might discuss such things) implictly
understand that GOTOs are a powerful language feature which has been
shown (over time) to be abused far more often that it was correctly used.

Well guess what!  The C++ feature which allows user-defined type conversion
operators to be *implicitly* applied (in some contexts) is "the GOTO of
strong typing".

Need I say more?

P.S.  If we got rid of implicit applications of user-defined type conversions
(while still allowing for *explicit* applications of user-defined type
conversions) I estimate that the current (enormous) complexity of the
overload resolution rules would be cut in half.  That would give the
implementors more time to work on other little problems (e.g. optimization).