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

[Van Snyder]

It's a bit late in the game to be pondering an alternative to CHANGE
TEAM.  Then again, clause 5 of 12-201 was empty, CHANGE TEAM was not
mentioned in N1930, and then CHANGE TEAM sprang full-grown from the
forehead of Zeus in 13-231, barely a month ago, and fewer than ten days
before the start of meeting 200.  There was very little discussion,
i.e., none in e-mail before meeting 200, and only a few minutes on each
of three days, only in J3, during meeting 200.

People complain that the standard is getting too big, so if we can
achieve the desired functionality with fewer or smaller mechanisms and
less text, that would be desirable.

To that end, I believe the functionality of the CHANGE TEAM construct
would be better served by a WITH TEAM ( <team-name> ) statement, similar
to logical IF, FORALL, or WHERE statements, that admits a subset of
action statements.  Even simpler would be to allow only CALL statements,
in which case it might be described as an optional WITH TEAM
( <team-name> ) prefix of a CALL statement, the latter then allowing
something like

  if ( do_this ) with team ( t ) call s ( ... )

which we might decide a WITH TEAM statement ought not to allow,
especially if a WITH TEAM statement admits an <if-stmt>.

Compared to the CHANGE TEAM construct, the amount of new syntax, and
associated constraints and description, would be reduced.

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.

A WITH TEAM statement, or a CALL statement having a WITH TEAM prefix,
would be an image control statement.  It would not be unreasonable to
constrain against alternate returns.

Alterations to the third paragraph of subclause 5.1 of N1967, and the
three paragraphs and note after C503 in subclause 5.3, would not be of
substantial scope or difficulty, and might result in slightly less text.

This would simplify invoking a collective subroutine on a subteam of the
current team, e.g. WITH TEAM ( T ) CALL CO_SUM ( A ).  A TEAM argument
for collective subroutines, not proposed in N1967, would never be
needed.

if WITH TEAM were a statement, SYNC TEAM might not be needed, using
instead WITH TEAM ( T ) SYNC ALL.  Unlike SYNC TEAM, however, this is an
image control applying to the entire current team, not only team T.  But
then, it's not obvious when reading 13-251/N1967 what SYNC TEAM means.

If SYNC TEAM means something like "If image M executes a SYNC TEAM
statement, and the value of SUBTEAM_ID() for image M is S, then
execution of the segment on image M of the segment following the SYNC
TEAM statement is delayed until every image of the current team for
which the value of SUBTEAM_ID() is S executes a SYNC TEAM statement
specifying the same team...," the same logic could be applied to WITH
TEAM, so that it would be an image control statement "for the specified
team" (whatever that means) not for the entire current team.

It's water over the dam now, but if we had provided the functionality of
the CRITICAL construct by a MONITOR prefix for subroutines, the text,
syntax, and constraints for that functionality would have been simpler.

We could still someday provide monitor subroutines, and then maybe print
the description of CRITICAL in obsolescent font, and then delete it.