There's nothing stopping you implementing these underscored requirements. So it really depends on what an underscored requirement means – and what it means is really what we chose it to mean.
To-date, underscores on things in the standard library means one of a few things:
- This should be an internal implementation detail, but we lack language features to make it so, so it's public but underscored instead.
- This is subject to change, full rights reserved to break/change it in the future. Use at your own peril.
- This is something you want to be able to implement on the protocol, but shouldn't be exposed to users of a type.
There's a lot less call for 1 these days, and 2 becomes vanishingly useful once we declare ABI stability.
That leaves 3 and we don't have a good way of spelling it. Another example would be Sequence._customContainsEquatableElement(_:)->Bool?, which a sequence implementation that has a better way of implementing contains can implement. It's a hook that the constrained extension on Sequence where Element: Equatable that supplies contains can call, giving you dynamic dispatch even though not all sequences contain equatable elements. We want to expose that to implementors of types that conform to Sequence, but a user should never see it on the concrete type when they're using it. So we underscore it. But you can still override it if you want to. It would maybe be better to do it in some more official way (say, with an @implementationDetail attribute or something).
The difference, like you note, is that the current things like this on Sequence have default implementations, whereas these don't. I don't know if that's a particularly critical dividing line. Ultimately you are going to need a fairly high degree of sophistication to make a type vectorizable. Having to know about these underscored customization points doesn't seem that big a deal. You will still get told about them if you try to conform to the type. Really all they hide stuff from autocomplete – which is what we want. It would be confusing for users of these types to see these things appear both as a nested type on T and as a top-level Vector3<T>