(j3.2006) (SC22WG5.4925) Alternative to CHANGE TEAM construct

[Bader, Reinhold]

Hello Bill, 

[...]
> >
> > With no construct, there could be no constraints on its relationship to
> > CYCLE, EXIT, or RETURN statements, or on branching, and therefore no
> > controversy where those constraints ought to be.
> 
> Without the construct there is no clear synchronization at the beginning
> and end of the construct.  Without the syncs,  allocating or
> deallocating a coarray within a "with team" environment would not be
> allowed, which would fail to satisfy the needs for teams as discussed at
> Markham.
> 
Given that coarray allocation and deallocation do their own syncs, I don't see why this additional
sync on the construct is necessary. Can you give an example  that illustrates what could go wrong
assuming CHANGE TEAM does no synchronization?


Regards
Reinhold