(j3.2006) question about generic resolution

[Van Snyder]

If we remove the feature of allowing a nonpointer actual argument to
correspond to a pointer dummy argument, one mode of repair for the
problem with ASSOCIATED is not available, viz. specifying explicitly
that the TARGET dummy argument of ASSOCIATED has the POINTER and
INTENT(IN) attributes.

The alternative is to describe ASSOCIATED using two interfaces, and the
term "does not appear" instead of "is not present."

Magic has been required to make ASSOCIATED work since the 1990 standard,
because the actual argument corresponding to the TARGET dummy argument
has always been allowed either to be a pointer or not a pointer.  If the
dummy argument is not a pointer the description is nonsense (absent
magic for which no attempt at explanation has been offered).  If the
dummy argument is a pointer magic was required to avoid violating the
rule that a pointer dummy argument couldn't have a corresponding
nonpointer actual argument.  If there are actually two sets of generics,
one with a pointer TARGET dummy argument and one with a nonpointer
TARGET, magic is required for generic resolution.

So the new feature actually makes ASSOCIATED work without the need
either for magic or a two-interfaces description.

On Tue, 2010-03-23 at 17:57 -0700, Aleksandar Donev wrote:
> On Tuesday 23 March 2010, Malcolm Cohen wrote:
> 
> > The "POINTER vs ALLOCATABLE" generic feature is fundamentally
> > misguided.
> I do not agree with this statement---this feature does have uses, and 
> this has been debated in WG5, which voted to put it on the list. No need 
> to revisit this just because Malcom disagrees with this decision.
> 
> I do agree that now is not the time to get into a "priority" selection 
> scheme for generic resolution, even if we are only talking about single 
> casing this particular problem. Generics should be inambiguous, and the 
> original POINTER vs. ALLOCATABLE proposal, which predates the "pointer 
> dummy target actual" feature, was (thought to be) inambiguous and thus 
> OK.
> 
> The "pointer dummy target actual" feature, which seems to cause a direct 
> collision here, was added later, perhaps without sufficient review, as a 
> response to a request by myself for some form of (guaranteed) copyless 
> argument association. It seems a cool feature, but I am not sure how 
> much use there is to it, especially considering that it can be done 
> "manually" by constructing a local pointer and pointing it to the actual 
> and then passing that on.
> 
> I do not like this "remove features because we found a collision and 
> someone thinks they are useless". We debated these features and in this 
> case, if anything, it is the other feature that is less useful.
> 
> That said, I am not yet certain how to solve this in the "best" possible 
> manner... I just know what I do not want to do :-)
> 
> Best,
> Aleks
>