In article <CrvKFD.B7q@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <rfgCru7tE.J4G@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>>In article <CrtIu5.960@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>>>
>>> As far as I know, built-in operators are not functions
>>>and so their addresses cant be taken. It appears that models
>>>of the built-in operators we be constructed "as if" they
>>>were functions for overloading purposes only.
>>>
>>> The compiler could generate an instance of
>>>
>>> operator+(int,int)
>>>
>>>which is addressable. Extension proposal from Ron?
>>
>>I might propose that as a very reasonable generalization (I hesitate
>>to use the word `extension' for obvious reasons) which could be quite
>>valuable in conjunction with templates, but quite frankly, I harbor
>>some vague hope that such a (separate) proposal will not even be
>>necessary, and that the obvious reasonablness and need for such
>>things will simply `fall out' of any good and comprehensive solution
>>to the general problem of defining (precisely, and at last) the rules
>>which govern the resolution of `operator calls' in cases where both
>>user-defined and built-in operators must be considered as resolution
>>candidates.
>
> The way I'd say that is "we should build a coherent model
>and not just vote in a set of ad hoc rules".

Hey!  Sounds good to me!

(I'm also in favor of motherhood and apple pie by the way.  And I'll stand
shoulder-to-shoulder with anyone who boldly proclaims that the committee
ought to do a `right and proper job'... at least until we get down to the
nit-picky little details of what the term `a right a proper job' actually
means in practice.  Then we might find that we're not in such terrific
agreement after all. (1/2 :-)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <CrtIu5.960@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
> As far as I know, built-in operators are not functions
>and so their addresses cant be taken. It appears that models
>of the built-in operators we be constructed "as if" they
>were functions for overloading purposes only.
>
> The compiler could generate an instance of
>
> operator+(int,int)
>
>which is addressable. Extension proposal from Ron?

I might propose that as a very reasonable generalization (I hesitate
to use the word `extension' for obvious reasons) which could be quite
valuable in conjunction with templates, but quite frankly, I harbor
some vague hope that such a (separate) proposal will not even be
necessary, and that the obvious reasonablness and need for such
things will simply `fall out' of any good and comprehensive solution
to the general problem of defining (precisely, and at last) the rules
which govern the resolution of `operator calls' in cases where both
user-defined and built-in operators must be considered as resolution
candidates.

(If Sam Kendall is tuned in, I would encourage him to give us *his*
views of this possibility.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <rfgCru7tE.J4G@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
>In article <CrtIu5.960@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>>
>> As far as I know, built-in operators are not functions
>>and so their addresses cant be taken. It appears that models
>>of the built-in operators we be constructed "as if" they
>>were functions for overloading purposes only.
>>
>> The compiler could generate an instance of
>>
>> operator+(int,int)
>>
>>which is addressable. Extension proposal from Ron?
>
>I might propose that as a very reasonable generalization (I hesitate
>to use the word `extension' for obvious reasons) which could be quite
>valuable in conjunction with templates, but quite frankly, I harbor
>some vague hope that such a (separate) proposal will not even be
>necessary, and that the obvious reasonablness and need for such
>things will simply `fall out' of any good and comprehensive solution
>to the general problem of defining (precisely, and at last) the rules
>which govern the resolution of `operator calls' in cases where both
>user-defined and built-in operators must be considered as resolution
>candidates.

 The way I'd say that is "we should build a coherent model
and not just vote in a set of ad hoc rules".

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA