gyro@kestrel.edu (Scott Layson) (03/26/91)
In article <4628@lupine.NCD.COM> rfg@lupine.ncd.com (Ron Guilmette) writes: >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. I agree that there should be someone involved who has the charter of keeping the language minimal. Look what happened to Ada. (I don't say that flippantly. I am in the middle of implementing a *#@%!! Ada front end.) However, I don't agree that the automatic application of user-defined conversions is something that should be removed. (Maybe this bodes ill for the job of the contractions group! :-) My personal candidate for dyking out is pointers to members, as it is easy to write static member functions that do exactly the same thing. Consider: struct A { // `struct' because protection doesn't matter for this example int i; virtual void foo(); static int& get_i(A& a) { return a.i; } static void call_foo(A& a) { a.foo(); } }; Now, within a member function of A, the expressions `&A::i' and `&get_i', though clearly not of the same type, are nonetheless equivalent in the more abstract sense that anything you can do with one you can do with the other (i.e., given an A and either the pointer to member or the pointer to `get_i' you can obtain a reference to the `i' of that A). Similarly, `&A::foo' and `&call_foo' are equivalent: given an A and either one of these, you can invoke the `foo' method of that A. (As you can readily see, this works even if `foo' is virtual.) Furthermore, that is all you can do with either of them. Granted, you have to write extra declarations to use the static member functions in this way. But how often is this really necessary? I have yet to have a need to do either one of these things. ----- Ron, I am aware that implicit application of user-defined conversions is a dangerous feature. But I have done too many really neat things with it ("too many"? alright, it was just one, but it was really REALLY neat) to want to see it go. Instead I submit that compilers should have the option of producing a listing of all user-defined conversions implicitly applied on each source line. It's not difficult for them to generate, and it admittedly would make certain debugging tasks far simpler. -- Scott Layson Burson Gyro@Reasoning.COM
wmm@world.std.com (William M Miller) (03/26/91)
gyro@kestrel.edu (Scott Layson) writes: > However, I don't agree that the automatic application of user-defined > conversions is something that should be removed. (Maybe this bodes > ill for the job of the contractions group! :-) My personal candidate > for dyking out is pointers to members... Exactly. And Tom Cargill's is multiple inheritance. (Mine? It's all the grotty C features like the declaration syntax and second-class arrays :-) There'd be so much ox-goring I don't think we'd *ever* make any further progress. (Actually, Tom's got a long list of things, and I could easily do without default arguments, too.) > My personal candidate > for dyking out is pointers to members, as it is easy to write static > member functions that do exactly the same thing. That's a really excellent point. It's a pity that static member functions weren't invented until quite a while after pointers to members; maybe we could have avoided the awful things if the order had been reversed. -- William M. Miller, Glockenspiel, Ltd. wmm@world.std.com