3 ms·

For what it's worth, that's my preferred solution in the long-term too. Speaking narrowly about the XCTest case: * It doesn't actually require runtime dynamis

For what it's worth, that's my preferred solution in the long-term too. Speaking narrowly about the XCTest case: * It doesn't actually require runtime dynamism (since you have a finite number of tests that can be statically enumerated). Following the principle of least power, don't do it if you don't have to. * A runtime-dynamism-based solution would require `dynamic` sprinkled on function definitions which would be a departure from source compatibility with Darwin XCTest which relies on the superclass and @objc inference on methods. * Mirror offers reads but not writes, and there is some sense that offering the ability to mutate through Mirror is uncharted design territory. Then there is debate about whether other "dynamic" cases can also be solved with static analysis. I am in the "probably not all of them" camp, but that still leaves some of them, and it would be good to study that boundary condition in more detail. With sufficiently robust static analysis you "can" implement your mirror trick for example (by code-generating a bigass extension to Mirror that just returns statically-analyzed data). Somebody will do that, and so I think upstream will be following how well it works out for them and letting the larger community build the case for or against the feature.

mikeash 10y ago
It's a really interesting point that you don't need runtime dynamism for this so maybe that shouldn't be the go-to solution. It's easy to just decide to do it that way because that's how it works currently.
eridius 10y ago
Honestly, determining that all methods that start with "test" are your unit tests is pretty bad. We do this because this was the most obvious solution in obj-c. A much better Swift solution is to instead use an attribute, such as `@test`, to mark test functions. This requires compiler support for now, but the long-term goal could then be to come up with a generic way of declaring and handling attributes.
- phink 10y ago
  It's not just methods starting with test, it's methods starting with test in a subclass of Test. It's a simple, working convention. Conventions are good, not pretty bad. Adding more stuff to the language only makes it more complex and requires more effort. I don't see this as a much better solution but as an over engineered one, as much of what Apple is doing these days.

mikeash 10y ago

It's a really interesting point that you don't need runtime dynamism for this so maybe that shouldn't be the go-to solution. It's easy to just decide to do it that way because that's how it works currently.

eridius 10y ago

Honestly, determining that all methods that start with "test" are your unit tests is pretty bad. We do this because this was the most obvious solution in obj-c. A much better Swift solution is to instead use an attribute, such as `@test`, to mark test functions. This requires compiler support for now, but the long-term goal could then be to come up with a generic way of declaring and handling attributes.

phink 10y ago
It's not just methods starting with test, it's methods starting with test in a subclass of Test. It's a simple, working convention. Conventions are good, not pretty bad. Adding more stuff to the language only makes it more complex and requires more effort. I don't see this as a much better solution but as an over engineered one, as much of what Apple is doing these days.