(j3.2006) Protected types

[Van Snyder]

On Sun, 2013-03-10 at 00:49 -0600, Bill Long wrote:
> 
> On 3/8/13 10:29 PM, Van Snyder wrote:
> 
> > In Fortran 2008, we introduced LOCK_TYPE, and prohibited it from
> > appearing in variable definition contexts.  TS 18508 introduces
> > LOCAL_EVENT_TYPE and TEAM_TYPE, and prohibits them from appearing in
> > variable definition contexts.  These are essentially limited (or
> > protected) types.
> 
> Variables of these types are prohibited from *some* variable definition 
> contexts, but not all.  Clearly the lock variable in a LOCK statement 
> appears in a variable definition context.

Surely a processor has a mark on its representation of a type to
indicate these restrictions.  If a processor has such a mark and
interprets it to mean what is described in 97-114 or 04-167 or 13-214,
and at least pretends that the mechanism of LOCK emanates from
ISO_FORTRAN_ENV, why have the mark only on three types defined in
ISO_FORTRAN_ENV?  Since a processor almost certainly has such a mark and
knows what it means, there appears to be very little additional effort
involved in allowing syntax to put the mark on a user-defined type.

> > Why can't we do the same for user-defined types?
> 
> The only request from the user community I've seen in this area is to 
> allow the PROTECTED attribute on a component of a type.

Maybe that's all you've seen from your user community, but the concept
has been around for nearly forty years.  Look at the "limited" attribute
for a type in Ada 83, and illustrations of its use in Ada textbooks such
as "Programming in Ada 95" by John G. P. Barnes or "Ada as a Second
Language" by Norman Cohen.  Maybe you didn't bother to read 13-214, and
the explanation therein of reasons for it, since it didn't get out of
JOR at 200.  When it was proposed in 04-167 and discussed in plenary
instead of only in subgroup, its hate-dislike-like-love score was
0-0-11-0.

>   Reference of 
> the component is allowed anywhere the parent is accessible, but 
> definition of the component is restricted to a module procedure in the 
> module where the variable is declared.   If I recall, this has been 
> proposed before, but never made the cut.

13-215 didn't get out of JOR at 200.