[J3] 18-156

[Van Snyder]

I had to leave Thursday night so I wasn't present to comment on Friday.

Propoer enumerated types are not a BIND(C) feature.  We already have
BIND(C) ENUM, introduced to make it easier to write C programs in
Fortran.  BIND(C) ENUMs can't be used for generic resolution, and have
no type safety at procedure references.

Steve wrote, concerning asynchronous subroutines: "Van wants other
models for this more like Ada."  I actually asked "How are asynchronous
subroutines different from Ada tasks?"  Tasks were in Ada '83 and are
well understood.  Maybe we could benefit from their experience rather
than proving George Santayana was right.

I have also previously proposed asynchronous blocks and a fork/join
construct.  Bill pointed out that an ugly equivalent can be faked by
putting a case selector inside a DO CONCURRENT construct.

I don't understand how degree trigonometric functions are helpful
without units support.  Units support would allow generic resolution to
select the correct one.

I would conditional expressions to short-circuit logical operators.
Conditional expressions can fake short-circuit logical operators, but
not vice-versa.  But short-circuit logical operators are better than
doing nothing.

In addition to LOG8 etc, SELECTED_LOGICAL_KIND with an argument that
gives the minimum number of bits, which the processor is free to
interpret as the maximum too.

I didn't have any time to consult with my colleagues when Steve said
"pick five for tomorrow," so I guessed.  My priorities weren't the same
as theirs.  Instead of ranges and views, they told me I should have
asked for.

1. Units
2. Support for containers
   2a. coroutines and iterators
   2b. updaters
3. Generalized subscripts -- subclause 2.4.1 in 18-119