Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!lupine.ncd.com From: rfg@lupine.ncd.com (Ron Guilmette) Newsgroups: comp.std.c++ Subject: implicit type conversions considered harmful: X3j16 "contractions" WG Message-ID: <4628@lupine.NCD.COM> Date: 25 Mar 91 09:10:29 GMT Sender: news@NCD.COM Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 86 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).