Re: Suggestion: Allow functions returning abstract types in certain situations

[Robert A Duff <bobduff@shell01.TheWorld.com>]

(sorry for email; I meant to post)

Adam Beneschan <adambeneschan@gmail.com> writes:

> On Wednesday, May 21, 2014 4:19:21 PM UTC-7, Robert A Duff wrote:
>
>> Not sure what you mean about "redispatch".  You can't [re]dispatch
>> without converting to class-wide.
>
> It didn't occur to me until later that your idea about forbidding a
> conversion from an abstract type to a class-wide type has to be a
> run-time check, not a compile-time check (or not solely a compile-time
> check).  Otherwise, if an operation of a concrete type converts a
> controlling parameter to a class-wide type, and then an abstract type
> is derived without overriding the operation, the code would then be
> converting the abstract object to a class-wide type unless it were
> checked at run-time.
>
> That's the sort of scenario I was thinking of when I mentioned
> Initialize/Adjust/Finalize doing a redispatch.

Ah, I see.  That's essentially the same as Dmitry's point 2.
I don't think it's specific to I/A/F.  Yes, it could be a
run-time check, but I'd much prefer a compile-time check,
even if it's rather restrictive.  Currently, dangling dispatch
is prevented by compile-time rules, and I'd like to keep it
that way.

- Bob