In some sense, a return statement in a concurrent loop is easier to understand, if we presume we are in a function searching (in parallel) for some item in a data structure, and we want to return the item as soon as any thread finds it. An exit statement in a concurrent loop is a bit harder to understand, since we would need a way to record the result of the winning thread somehow. Perhaps we would want to allow some code associated with the exit statement that occurs after all of the other threads have been aborted. Perhaps "exit loop then record winner;" might be a syntax indicating that the record winner code is to be executed after the loop has effectively been stopped, but still in the context of the winning thread, with visibility on the local variables of the loop body containing the exit loop then ... construct.
For example, using the generalized for loop from the previous posting:
var Winner : Node := null; for T := Root then T.Left || T.Right while T != null concurrent loop if T.Key == Desired_Key then exit loop then Winner := T; end if; end loop;At this point Winner is either still null if no node in the tree has the Desired_Key, or is equal to some node whose Key equals the Desired_Key. If there is more than one such node, it would be non-deterministic which such node Winner designates.
Clearly this kind of brute force search of the tree would not be needed if the tree were organized based on Key values. This example presumes the Key is not controlling the structure of the tree. Also note that if this were a function whose whole purpose was to find the node of interest, the exit loop then ... statement could presumably be replaced by simply return T and we wouldn't need the local variable Winner at all.