SignatureView["verify"] takes any ByteView

[Peeja]

Rationale

SignatureView["verify"] can always take any ByteView—meaning it won't misbehave or throw an error. Presumably, it will only succeed if the types match (along with the actual data), but you're allowed to call verify() when it might fail. In fact, that's its whole purpose. 🙂

Before this change, SignatureView is contravariant in its type parameter T. This means that a SignatureView of a more specific type, like SignatureView<string>, cannot be assigned where a SignatureView of a broader type is expected, like SignatureView<unknown>. The reasoning from TypeScript's perspective makes sense: SignatureView<unknown>'s verify() can be called with any ByteView, but SignatureView<string>'s verify() can only be called with a ByteView<string>. If you assign a SignatureView<string> to a SignatureView<unknown> location, the code will no longer know to call verify() on it only with a ByteView<string>. It would appear perfectly valid to TypeScript to call it with a ByteView<number>, for instance, which is supposed to be invalid.

But actually, calling it with a ByteView<number> would be fine, it would just (presumably) return an { error: ... } object to signal that the signature doesn't verify.

Playground Example

This becomes an issue, for instance, in Ucanto, where function which takes a Receipt, but doesn't care what the type of its out value is, can currently only take a Receipt whose out type is exactly as unknown.

Playground Example