Support 'in' as an infix operator for membership test

[ben-albrecht]

Add in as an infix operator in a way similar to Python, supporting such cases:

if value in Range { }

if value in Domain { }

if value in Array { }

Maybe strings too (#11439):

if subString in String { }

This form of in could potentially overload the D.contains() method.

This grammar must be implemented carefully such that:

for i in D

is not parsed as:

for D.member(i)

[bradcray]

Fleshing out a bit what I referred to on email yesterday about the potential confusion for 'x in D' to be a membership test in spite of its attractiveness in many situations:

    var D = {1..n};            // this is a domain declaration
    for i in D do ...          // this is a loop
    if (3 in D) then ...       // this is a conditional
    var I: [D] int = ...;      // this is an array
    var Mask = (I in D);       // this is an array of bools formed by promoting the membership test
    for m in Mask do ...       // this is a loop over 'Mask'
    for i in (I in D) do ...   // as is this, effectively, just removing the need for 'Mask'
    for 1..n do ...            // as is this (a loop's index need not be named if not needed)
    for (I in D) do ...        // so this is effectively like a loop over Mask with anonymous index?
    for I in D do ...          // but this case seems ambiguous...

Specifically, in the last case, is 'I' the name of an index variable, or is this a loop over the promoted 'Mask'-like expression 'I in D' with an anonymous index variable?

I don't think this is a killer for the proposal -- I think we could choose to resolve the ambiguity by saying that in the loop context, the loop wins (i.e., the last statement is declaring a new loop index named 'I' that will take on all indices in 'D'). But it is a potential point of confusion. That said, I think it's also relatively unlikely to come up in "real codes" (and we could favor a coding style that would strive to steer clear of such ambiguities).

Anyway, this is the main reason I've never proposed it before this conversation.

[benharsh]

A future exists for this request: test/arrays/stonea/inForMembership.chpl

[ben-albrecht]

I think Python avoids these ambiguity issues since an in expression can never produce an iterable.

I think we could choose to resolve the ambiguity by saying that in the loop context, the loop wins

Agreed. Though, it bothers me that the last 2 cases would be different, due to to parentheses:

for (I in D) do ..
for I in D do ..

Do parentheses impact the interpretation of a for loop expression in other contexts, or would this be a unique case?