(j3.2006) Would there be a technical problem if...

[Van Snyder]

On Wed, 2018-01-17 at 15:11 +0000, Bill Long wrote:
> > On Jan 17, 2018, at 8:54 AM, Damian Rouson
> <damian at sourceryinstitute.org> wrote:
> > 
> > Such a feature would be especially nice for use with type-bound
> operators:
> > 
> > type(vector_field) : u(3), v(3), w(3)
> > u = v .dot. w
> > 
> 
> I don?t find this example persuasive. Firstly, the obvious way to do
> something like this is to define the operator generic in the module
> where the type is defined and supply the implementation function in
> the same module.  I don?t see how this example has anything to do with
> OOP or type-bound procedures.  For simple computations, tbp are almost
> always the wrong choice for performance....

My example was a dump routine.  Performance didn't matter much.  It was
type-bound purely for convenience, so I wouldn't need to go back to the
head of the module to put in a USE statement, or insert a BLOCK
construct, just to get some debugging output.

Anyway, I still don't know whether there's a technical problem for the
standard or for implementations to allow the passed-object argument to
be an array.

Is a TBP the wrong choice for performance because we require the
passed-object dummy argument to be polymorphic?  In most of my code, the
only polymorphic objects are passed-object dummy arguments.  Couldn't an
implementation compile two versions of a TBP, one that assumes the
passed-object actual argument is polymorphic, and does runtime dispatch,
and the other that knows it's not polymorphic and doesn't do runtime
dispatch?  Surely the clanking machinery of generic resolution could
figure out which one to call at compile time if the declared type of the
actual argument is the same as the declared type of the dummy argument.