(j3.2006) (SC22WG5.5914) Preview of possible feature survey

[Van Snyder]

On Wed, 2017-07-12 at 22:25 +0000, Bill Long wrote:
> Five is negotiable. Maybe 8, or even 10.  But 50 is obviously unfair
> to the committee, especially if they are ones repeatedly rejected in
> the past.  Such abuse would be unacceptable. 

There is a difference between "That's a terrible idea that we'll never
consider" and "That's a good idea but there's more important stuff to do
right now."  I don't propose to bring back proposals that had negative
opinions recorded in the 2004-05 spreadsheets.  For example, using
function result types as an additional criterion for generic resolution
(rejected 2-10) won't be coming back, unless we do enumerated types, for
which it's crucial to make them work smoothly.  New types, not type
aliases (accepted for further consideration 10-1 in 05-143r3) will be
returning.  Type alias, which displaced new types, is an enormously
inferior idea that fortunately was abandoned to trim the work plan.

Proposals for 2015 that were vetoed in subgroup at Delft and Las Vegas
but never discussed in plenary were not rejected (being discussed by
three people who voted 2-1 not to put the proposal forward isn't
rejection in my book), and some of those might be coming back.

> And certainly none for parameterized modules, which, as you note,  we
> have already rejected.

Parameterized modules were not rejected.  They had the third highest
priority in 05-143r3, after coarrays and rewriting attribute
requirements.  They were above DO CONCURRENT and CONTIGUOUS.  There were
only nine "A" priority items in 05-143r3, and the other eight were
implemented.  There were none with a higher "hate dislike like love"
score (0 0 7 4), and the only one with the same score was to get a
logical I/O unit number (became NEWUNIT in OPEN).

Parameterized modules were displaced by macros, which were thought to be
simpler to describe and implement, to trim the work plan.  Macros were
then abandoned (but not really rejected either) to trim the work plan.

People have been talking about generic programming in Fortran for years.
Why isn't it OK to revisit the question of how we ought to provide
support?  There was offline discussion precisely of parameterized
modules in Garching, where we explicitly decided that online discussion
of new features was premature until we had developed a procedure to
process them.  One of the propositions in the draft plan for gathering
requirements was to ask C++ users why they fled from Fortran.  That
question has been asked and answered numerous times:  To get templates.
Users did not abandon Fortran in favor of C++ to get CPP, and the reason
"to get OOP" doesn't hold water any more.

If we had done parameterized modules in 1990 (there was already seven
years' experience with them in Ada by then, and no experience in any
language with PDT), we probably would not have done parameterized
derived types, and there would not now be an integration gap between PDT
and type-bound procedures.  Maybe if we do parameterized modules we can
print all the PDT stuff in small type.

Some things that were "rejected" in 04-302 we did anyway.  For example,
we did an entire TS on further interoperability (hate-dislike-like-love
score was 1 11 0 0).