Perhaps the term "implicit" reserved for those cases without need for notice or control, and these particular conversions are universally applicable and acceptable, so a language-level policy is best.
This is well put. The cases affected by this proposal would not benefit from notice or control. The change does nothing more than reflect the reality of the language that the API was designed for. A language-level policy fits well.
Wouldn't making it explicit help the reader?
In general, I strongly prefer explicit conversions. In the narrow use cases affected by this proposal there would be no benefit. It would decrease readability. And it would largely defeat the purpose of being able to port code that passes pointers between C APIs without figuring out some peculiar Swift construct for handling the pointers. There simply isn't any interesting conversion happening that the reader needs to be aware of.
In practice, this change only affects the use of existing C APIs that were designed anticipating exactly the kind of implicit pointer type conversion proposed here. The goal of this proposal is to allow Swift programmers who are not in a position to make changes to a library to simply use C APIs as they were designed. We intentionally don't want new libraries making use of this conversion. They should instead follow Swift's consistently strict rules for pointer types.
With the proposed solution, we simply say that the C compiler follows C semantics and the Swift compiler follows simpler, more consistent Swift semantics. Having Swift fully adopt C semantics with all its legacy warts causes a bigger problem for Swift in the long term. That's discussed in the proposal, but we can talk more about that if needed.
A generalized solution to this specific interop problem quickly leads to over-engineering and opens up new problems. If we had two pointer types with different semantics, the language's memory model would need to define both semantics and support multiple pointer aliasing modes.
Being able to move back and forth between more and less strict pointers within the same language opens up real safety holes. If you have two valid aliasing C pointers, then convert them both into Swift pointers, you can end up with undefined behavior. The C APIs that require this sort of pointer aliasing never call back into Swift. So the proposed solution is quite safe in practice.
I'm very sympathetic to the broad push-back against adding more pointer types to Swift. UnsafePointer mostly is the "C interop" pointer type. In time, Swift APIs should move away from using pointers. This should accelerate when Swift has alternative, efficient low-level "buffer types".
