I'm not sure I would go so far as to say I want to discourage engineers from posting here with comments on additional types or changing names. But I do feel like I am personally not going to prioritize actively engaging with that feedback at this moment in time while I believe the more urgent priority for us remains unresolved.
Correct. I can think through this some more but my basic ideas so far were in the previous comment. And anyone that wants to expand on their previous feedback is welcome and encouraged to respond.
What I'm wondering is if there is some sort of "clean" way to attempt to build a framework here that we can not only define precise semantics of isIdentical on concrete types like String… but that framework is then flexible enough that a future type like StaticString could potentially build isIdentical and still fit the same sort of overall design. So there is some overall consistency between these implementations even if we also want individual types to perform and communicate different refinements on what these "implicitly inherited" semantics communicate. And if all that also conceptually "backdeploys" to the existing isIdentical implementation on Span then that would be a great side effect.
I also want to try and think forward because I also want this to ship on adjacent libraries like Foundation:
And Collections:
So what can we build here that is "precise" enough to resolve the incoming feedback about semantic ambiguity and also "flexible" enough to "fit" on new types that might not even exist yet? I don't have an easy answer yet but I can try and put some more thought to that.