rfg@lupine.ncd.com (Ron Guilmette) (03/25/91)
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).
tom@ssd.csd.harris.com (Tom Horsley) (03/26/91)
>>>>> Regarding implicit type conversions considered harmful: X3j16 "contractions" WG; rfg@lupine.ncd.com (Ron Guilmette) adds: rfg> Well guess what! The C++ feature which allows user-defined type conversion rfg> operators to be *implicitly* applied (in some contexts) is "the GOTO of rfg> strong typing". rfg> Need I say more? rfg> P.S. If we got rid of implicit applications of user-defined type rfg> conversions (while still allowing for *explicit* applications of rfg> user-defined type conversions) I estimate that the current (enormous) rfg> complexity of the overload resolution rules would be cut in half. That rfg> would give the implementors more time to work on other little problems rfg> (e.g. optimization). I agree with this, and I don't even care how hard it is to implement the overload resolution rules. I just want to write code that really does type checking and only does the conversions where I say "I really meant that." Right now in C++, if I define my own type conversion functions (because I actually do need to use them sometimes), I can't get any error messages out of the compiler, because it thinks it is OK to implicitly apply the functions. (I suppose the compiler could be made to generate a warning or caution in this case, but that would cause its own set of problems, and most (all?) compilers don't generate such messages). I can't get the benefit of strong type checking and also provide a way to do the conversions naturally. (Yes, I know I can get around it other ways, like defining lots of silly generator functions or something like that). -- ====================================================================== domain: tahorsley@csd.harris.com USMail: Tom Horsley uucp: ...!uunet!hcx1!tahorsley 511 Kingbird Circle Delray Beach, FL 33444 +==== Censorship is the only form of Obscenity ======================+ | (Wait, I forgot government tobacco subsidies...) | +====================================================================+
cok@islsun.Kodak.COM (David Cok) (03/26/91)
In article <TOM.91Mar25123217@rcx1.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) writes: [ Prior post deleted about not having implicit conversions] > >I agree with this, and I don't even care how hard it is to implement the >overload resolution rules. I just want to write code that really does type >checking and only does the conversions where I say "I really meant that." > >Right now in C++, if I define my own type conversion functions (because I >actually do need to use them sometimes), I can't get any error messages out >of the compiler, because it thinks it is OK to implicitly apply the >functions. (I suppose the compiler could be made to generate a warning >or caution in this case, but that would cause its own set of problems, >and most (all?) compilers don't generate such messages). > >I can't get the benefit of strong type checking and also provide a way to >do the conversions naturally. (Yes, I know I can get around it other ways, >like defining lots of silly generator functions or something like that). I, on the other hand, like implicit conversions, but agree with the sentiment that wishes that they could be controlled. Use constructors and operator X to define what explicit conversions are allowed and then some other mechanism to say which of these explicit conversions should be used as automatically applied implicit conversions. The two concerns should be made more orthogonal. David R. Cok Eastman Kodak Company cok@Kodak.COM
niklas@appli.se (Niklas Hallqvist) (03/28/91)
cok@islsun.Kodak.COM (David Cok) writes: :In article <TOM.91Mar25123217@rcx1.ssd.csd.harris.com> tom@ssd.csd.harris.com (Tom Horsley) writes: : [ Prior post deleted about not having implicit conversions] :> :>I agree with this, and I don't even care how hard it is to implement the :>overload resolution rules. I just want to write code that really does type :>checking and only does the conversions where I say "I really meant that." :> :>Right now in C++, if I define my own type conversion functions (because I :>actually do need to use them sometimes), I can't get any error messages out :>of the compiler, because it thinks it is OK to implicitly apply the :>functions. (I suppose the compiler could be made to generate a warning :>or caution in this case, but that would cause its own set of problems, :>and most (all?) compilers don't generate such messages). :> :>I can't get the benefit of strong type checking and also provide a way to :>do the conversions naturally. (Yes, I know I can get around it other ways, :>like defining lots of silly generator functions or something like that). :I, on the other hand, like implicit conversions, but agree with the sentiment :that wishes that they could be controlled. Use constructors and operator X :to define what explicit conversions are allowed and then some other :mechanism to say which of these explicit conversions should be used as :automatically applied implicit conversions. The two concerns should be made :more orthogonal. Yeah, that sounds fine! What about yet another overloading of an existing keyword? (Don't we all just LOVE reusing keywords :-) operator int() auto; Well, I'm not too concerned about pushing this issue. I just thought up the syntax. This would of course break lots of existing code. So... It needed rewriting anyway ;-> Niklas -- Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!sunic!chalmers!appli!niklas