🚀 go-pugleaf

>>>>> 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...)               |
+====================================================================+

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

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

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

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