It is true that the current implementation allows us to safely use an API when all the type parameters in its signature have been constrained to something non-dependent,
Presumably you mean the proposed implementation? Otherwise, I cannot imagine what you're saying.
but constraints are not an explanation as to why we cannot use them otherwise,
Never claimed they were an explanation of anything. I said my proposed syntax points explicitly to the cure for the missing API.
nor an answer as to whether we could do something about it in the future.
Sorry, I don't know what you mean by that. What is “it?”
Similarly,
P where A == Intis simply a refinement,
Not in the usual sense we use the word “refinement,” which refers to what's sometimes called ”protocol inheritance.“ I'm not sure what you mean by calling it a refinement.
not necessarily the reason you could call
f() -> A where A: SignedIntegeror a similar method featuring a different associated type on that type.
I'm sorry, I'm afraid I don't understand what you're trying to say here either. How could the name of a type (P where A == Int) be the reason for anything?
It seems like a more accurate diagnostic could make a decent enough explanation compared to any of the syntaxes hitherto mentioned.
sigh; diagnostics are not a substitute for understandability.