(j3.2006) Comment concerning TEAM_TYPE

[Van Snyder]

On Tue, 2013-10-08 at 13:56 +0900, Malcolm Cohen wrote:
> One might also wonder about the utility of such things as
>    Type(team_type) x
>    Call s(Transfer(123,x))
> I mean, this is bad enough with LOCK_TYPE but with TEAM_TYPE the
> results should 
> be hilarious.  Some additional requirements along the lines of "the
> result of a 
> function reference shall not be of type TEAM_TYPE" might be worth
> considering.
> 
> While I thinking of strange things, this seems to be valid:
>   CLASS(*),POINTER :: a,b
>   TYPE(team_type),TARGET :: x
>    a => x
>   FORM TEAM(a,13)
>    ALLOCATE(b,SOURCE=a) ! TEAM_TYPE with POINTER attr?
>    SELECT TYPE(b)
>    TYPE IS (team_type)
>       SYNC TEAM(b) ! b is a copy of a?
>    END SELECT
>    DEALLOCATE(b) ! Deallocating TEAM_TYPE is ok?
> 
> ...perhaps we ought to consider forbidding TARGET with TEAM_TYPE too,
> otherwise 
> half of the constraints are pretty pointless.  Or adding runtime
> requirements.

Maybe objects of type team_type (and event_type and lock_type) ought to
be prohibited as arguments, or at least as the MOLD argument, to
Transfer.

One might also wonder about the utility of named constants of team_type.
Sure, you can't create them without the constructor, but that's a
different issue.

Do we want to allow variables of lock_type, team_type or event_type in
common?  There is an indirect prohibition for variables of event_type
and_lock_type because they have to be coarrays, but subclause 5.2 of the
TS doesn't prohibit it for team_type indirectly because team_type is
prohibited to be a coarray, and the TS doesn't say team_type doesn't
have the SEQUENCE (or BIND) attribute.

I think it's a pipe dream that the coarray TS will be ready for
publication after 202.  There are too many brand-new ideas, especially
concerning teams, that haven't been tested, or thought through far
enough.