There are several List methods which depend on equality checking:

• index
• contains
• containsAll
• remove

All of these methods use the == operator (shortcut for Obj.equals). But sometimes you want to perform these operations with the === same operator. So I've added new methods:

• indexSame
• containsSame
• containsAllSame
• removeSame

I also added a List.findIndex method which works just like List.find but returns the index instead of the object.

I also had a request to expose System.identityHashCode which I've added as Sys.idHash. If you happen to know what the equivalent .NET API is please let me know.

I don't believe it's syntactically possible in Fan at this point, but it would be nice if you could make this more general by sticking to the original four methods you list above and have these methods accept an equal closure parameter which would default to ==.

This way, not only can we override the behavior to use === if we need to, but we can use any arbitrary equality method (e.g. equalsIgnoreCase()).

Is it possible to pass method literals in parameters? (like : in Ruby)

-- Cedric

I considered that approach, but this is so commonly done that I think they should be readily available without having to pass in a closure.

Plus the key methods above do already have equivalent closure version:

list.index("a")
list.findIndex |Str s->Bool| { return s.equalsIgnoreCase("a") }

list.contains("a")
list.any |Str s->Bool| { return s.equalsIgnoreCase("a") }

I don't have a closure version for remove, but you can do that with findIndex and removeAt (it seems a bit unlikely).

I do not have slot literals in the language currently. Although currying a method is pretty close:

list.findIndex |Str s->Bool| { return s.equalsIgnoreCase("a") }
list.findIndex(&testMethod)
list.findIndex(&"a".equalsIgnoreCase)

When you curry a method without binding any parameters, you can get back the original method from Func.method:

fansh> f := &Int.plus
|sys::Int,sys::Int->sys::Int|
fansh> f.method
sys::Int.plus

By the way, any chance for changing &Int.plus to Int.&plus? I think it's clearer (though different from C), and it would make chaining easier (as in Int.&plus.method).

Also, any way to bind a getter and setter at one go? On this subject, that's where the & would act more like C. For instance if &name returns a bound field reference with getter and setter methods, it's almost like old-timey (but here type safe) pointers.