Brainstorming customizing matchers

[grynspan (Jonathan Grynspan)]

@allevato

That does sound interesting. I'm assuming it would expand to other kinds of checks as well? Looking at the macro expansion for #expect(y.isSuperset(of: x)) we could have some kind of requirement on CustomExpectable that would be called if __checkFunctionCall fails, and it would receive as one of its arguments the name of the method, and it could look at that and compute the set difference? That could be feasible.

The expression passed to #expect() needs to be valid before the macro is expanded. So if the expression is a member function call to a member function that doesn't exist (e.g. Array.isSuperset(of:)), compilation will fail. The specific case of isSuperset(of:) is therefore constrained to types conforming to SetAlgebra. Set in particular conforms to Collection, and collections already have special casing in swift-testing—we haven't extended that special-casing to member function calls, but we could do so easily. With that in mind, this sort of approach is likely to be more useful for things like protobuf, which the testing library doesn't know about.

@allevato

Thinking about the analogy with custom string interpolations some more, it would be nice if that was a bit more automatic, like if the macro could generate a call to some function that has a matching name and signature but returns diagnostic information. But it's not immediately clear how you'd make that work in a type-safe way, because the macro can't conditionally generate that diagnostic call based on whether that helper function exists somewhere or not.

Macros do not have type information during expansion, only syntax tree information, so they cannot tell if an arbitrary expression results in (or is composed of) a value of a particular type. Any overload of __check() that the macro expansion calls therefore needs to have a generic fallback (which is usually straightforward to provide, at least.) Does that clarify things at all?