To make is even more explicit. My idea of a "pure" function will not change behaviour by moving it from one type to another, or to or from the global scope. A "pure instance function" is simply a practical place to put it, to limit accessibility, not a part of its behaviour.
Ok, I think we're at the crux of the matter here. The disagreement is fundamentally over whether a pure function is allowed to operate on implicitly passed arguments as well as implicit ones. I think it's acceptable to disagree on this point. To my mind, my mental model of Swift instance methods is always that they have an extra implicit argument, and should always be thought of as such, but I understand wanting to conceptualise that argument as being somehow different than the others.
I think this is a point where it is reasonable to disagree.
1 Like
I'm not even certain I disagree 
I may be swayed in one direction or the other, based on examples of use cases.
But in this instance, the motivating use case is to be able to factor out closures that do not operate on self as "pure" functions (on the instance) for convenience, code organisation, or code reuse; and at the same time avoid having to deal with capture of self (since it is not used, and in this context: pure).
I'm sure other use cases have different tradeoffs.
I didn't fully understand everything in this thread. But I stumbled upon this and wasn't sure how it's being handled.
I find it dangerous that self could be captured in those cases, so my suggestion would be to at least make it necessary to explicitly write self. in front of the function one is passing.
2 Likes