Allow [] as a synonym for Set.contains()

[DartBot]

This issue was originally filed by rice@google.com

---

It would be a nice shorthand to define '[x]' on a set to return the same value as s.contains(x).

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Added Triaged label.

[rakudrama]

Would you expect s['fred'] = false; to remove the element?

I think consideration of what is a nice API for Set should happen at the level of the whole library.
For example, should it be possible to implement a data structure that is both a Set and a List (and a PriorityQueue)?
If the interfaces Set, List, PriorityQueue are considered in isolation then conflicts in usage will happen.

I personally would prefer to write
   if('fred' in s)...
than
   if (s['fred']) ...

[DartBot]

This comment was originally written by aj...@gmail.com

---

Me too, coming from a python background. x in y is very nice syntax, and more immediately obvious.

[lrhn]

I don't generally mind redundance if it makes it easier to express what you want, but I think two functions that does exactly the same is too much.
A set is not a Map to bool, nor is it a function to bool (you could write set(x) too to get the same result as set.contains(x)). I'd prefer to keep separate concepts distinct.
If you want a map, you should be able to somehow get a Map<T,bool> view of a Set<T> so you can treat it as a Map (fully with assigning false to the map meaning remove from the set), but it won't be one itself. (If you want a it as a function, just extract the "contains" method).

In other words, I don't think we should do this. The []-operator is for indexing into something. A set is, conceptually, not indexable by anything. The operator doesn't really match the operation.

If 'in' was an operator, I wouldn't mind using it, but it isn't.

[lrhn]

Added WontFix label.