jerry gay wrote:
i don't understand the drive to have unique test identifiers. we don't have unique identifiers for every code statement, or every bit of documentation. why are tests so important/special/different that each warrants a unique id? that aside, this functionality sounds like it can be encapsulated in a module, if desired. as it stands, i can't see a reason reason it *has to* be made available in the core.
I have a mental model that says, for each implementation, there is a mapping that tells us which tests are runnable, non-runnable, etc. Imposing such information from without is difficult (or fuzzy) if tests aren't identifiable (giving a name to a group of tests allows a whole group to be enabled/disabled as one).
I'd point out that we do, in fact, name statements when it makes sense to do so: with nested loops, labels allow you to refer to output loops explicitly for C<next> or C<last> statements (also C<goto>).
The fact that it's possible to name something doesn't require you to do so. But the ability name things like tests is a useful capability, in that it makes it possible to programmatically enable/disable them without touching the source code that defines them.
A spec-test is (or should be) different from an ad-hoc test. I want to be able to say "test S09.237 passes on pugs but not on Rakudo" (perhaps with a nicer name). Unique identifiers allow comparisons of specific tests across multiple implementations, and over time. It is possible to derive IDs using line numbers (perhaps block-relative), but that's only a good idea if the test suite is reasonably stable (and it requires tool support).
Actually, if the truth be known, I don't really want to say that. I much prefer to define behavior using properties, and then say "random seed 35467 generated a test that caused assertion XYZ to fail" (or "random seed 54578 generates a test that gives a different result on Rakudo Vs Pugs"). Specific hand-coded directed/focused tests are usually a last resort in my line of work.
I don't care if the functionality is "Core" or "Module" -- I'm not even sure that there's a distinction. I think the question is more "is it specified as part of the language, or not" -- and if it's used by the spec of the language then it seems reasonable to specify it.
