(j3.2006) question about generic resolution

[Malcolm Cohen]

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.

Well, we voted to put it on the "Allowed" (not "Required") list.

> No need
> to revisit this just because Malcom disagrees with this decision.

That is not what I wrote.  That is not what I suggested.  That is not an 
accurate characterisation of my opinion of the decision either then or now!

Perhaps I wasn't clear enough: this feature has a *fundamental* conflict with 
the pointer-targetting feature (or whatever we want to call it).  The ambiguity 
here is *fundamental*.  But this feature was meant to be a cheapo "hey, we can 
tell the difference here - that there is no ambiguity - so let's do it for this 
one special limited case".  But it turns out that as we wrote the new standard, 
it is ambiguous after all.

That's why I wrote that it was "fundamentally misguided".

> I do agree that now is not the time to get into a "priority" selection
> scheme for generic resolution,

Well, we are in agreement after all then!

> 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.

Ah, so we can blame you for this mess?

Since this particular feature has also been kicking around for a while and has 
been suggested by a number of different people, I don't think it is fair to 
blame you though.  After all, I am the author of the paper that added it!

> 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.

Similar remarks suitably modified apply to the generic rule tweak too.

> I do not like this "remove features because we found a collision and
> someone thinks they are useless".

That was not the reaction, and not actually the suggestion.

The suggestion was that we should remove the potential for ambiguity.  That this 
would effectively remove the "generic feature" in its entirety is unfortunate, 
if perhaps unsurprising given the extremely limited nature of its "tweaking" of 
the generic rules (and that said tweaking was all the feature was).

I have spent considerable time and effort over the years improving the generic 
ambiguity rules, making them less restrictive in what people can put into a 
generic overload; so the suggestion that I am against such things is entirely 
mistaken.  What I *am* against is introducing ambiguity, especially when the 
result adds such a small amount of functionality.

> We debated these features and in this
> case, if anything, it is the other feature that is less useful.

That is certainly not my experience.  Even without CONTIGUOUS, I quite 
frequently stumble across situations where there is a minor problem that the 
"auto-targetting" feature would solve cleanly.  I have never personally wanted 
to disambiguate between POINTER and ALLOCATABLE in a generic -- I have wanted to 
disambiguate various other things that we still cannot do, but not those two! 
So from where I am sitting, this particular generic tweak is very limited in use 
indeed: not zero, not useless, but not very 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 :-)

As I wrote, the conflict is fundamental.  Our choices are limited to effectively 
removing one or the other feature, or introducing a "priority" scheme to 
disambiguate this case.  *NONE* of those choices are particularly "good".  That 
doesn't mean we don't have to do one of them though.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.