[grynspan]

This PR adds an experimental property to Test.Case to allow callers to get the test case's arguments as a type-erased array. For example:

if let testCase = Test.Case.current {
  for value in testCase.argumentValues {
    print("\(value): \(type(of: value))")
  }
}

We already have an arguments property of a type that we do not intend to make API, so the new property is named argumentValues pending any SPI renaming.

Resolves #1889.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.

[stmontgomery]

I know this is just an SPI at the moment but assuming the intention is to advance it to a public API, I'm interested in discussing the merits of exposing just this one property vs. exposing the backing Test.Case.Argument type and an array of argument instances. Having a richer type to represent an argument could have some advantages worth weighing.

Of course, nothing prevents us from pursuing both; they could complement each other. Said a different way, I'm not certain yet whether I agree with this statement from the PR description (emphasis mine):

We already have an arguments property of a type that we do not intend to make API, so the new property is named argumentValues pending any SPI renaming.

I think we should consider both ideas, and that could take place during an API pitch thread.

[grynspan]

I think we should consider both ideas, and that could take place during an API pitch thread.

The comment is more to the point that I couldn't go and name the new property arguments because it'd break against the existing property, and any renaming would need discussion. So I think you're just agreeing with me. :)

[grynspan]

In any event I'm also fine leaving this specific PR on the table. I think there's value in allowing these values to be accessible but I don't feel too strongly about the precise shape of the API we would add.

Fortunately the values are all constrained to Sendable & Copyable so we can do this without hurting ourselves too much.

[grynspan]

Reviving this PR as Span and the new Iterable protocol will allow us to support ~Copyable arguments in the future.