(j3.2006) question about generic resolution

[Malcolm Cohen]

Bill Long wrote:
> Independent of what we decide to do, we need to decide when to do it: Now as 
> an edit to N1814 [enough people have not voted yet that a ballot groundswell 
> would be possible],

Since there isn't immediate universal agreement, I don't see how this can be 
possible even if I (and others) were in favour of making un-mandated (no ISO 
ballot comment) technical changes at the DIS stage.  On principle, I am not in 
favour.

> or as an interp later.

There is no doubt that this is what we ought to do.

>  If we decide on an interp,  I would still like to have the decision now

No can do.

> since it affects currently ongoing implementation work.

Then don't do that work.  Or do it and put a health warning on it (call both of 
them "extensions" and give an error for the potentially ambiguous case should be 
safe).  Whatever.  Your desire to get all the boxes ticked first is 
understandable but does not override our duty to make the right decision using 
the right process.

> \begin{OpEdComment}
>    This situation points out the inherent weakness in the argument "We should 
> add feature xxx because I can't think of a reason not to.".
> \end{OpEdComment}

And also inherent weaknesses in following the schedule, and in proudly 
proclaiming our new features early on.

Aleks Donev wrote:
> 4) Modify the rules so that one cannot write a generic like this. For example, 
> do not allow "pointer, INTENT(IN)" (caps serve an emphasis purpose here) and 
> "allocatable" to be used for disambiguation.

Now that *is* an improvement.  Still a bit icky, but that's not unusual for us.

Aleks also wrote:
> make generics preference-based (something Kurt promised to do when I first 
> joined J3 but unfortunately he left before it got done).

No-one on the committee was, or is now, in a position to promise that.  There is 
a big technical can full of worms there, and beside it is a big can full of 
political worms.  Few/some/many/most people on the committee(s) might prefer 
overloads to be unambiguous - that is the biggest political worm.  The biggest 
technical worm might be that there are many possibilities for what 
"preference-based" really means.  Another big political/technical worm is that 
some people might prefer to get their error messages when the library author 
writes a bad overload, not when the user tries in vain to call it.

I don't recall anyone actually making the case for this new suggested feature 
during the F2008 feature selection process either.  Maybe I have just forgotten 
(or missed that meeting), but if not: then not making the case => not going to 
be done.

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