Deprecation (deliberately) doesn't affect overload resolution, so if this doesn't go into Swift 5 you'll need to leave both overloads forever, for people backwards-deploying. (Or we need an always-emit-into-client annotation, so that we can backwards-deploy the new thing.)

If someone's made a protocol that matches the existing signature, we don't want to break them either.

@belkadan, excellent points. If this doesn't go into Swift 5, I imagine putting @available(introduced) on the new API and @available(deprecated) on the old one without obsoleting it.

I have no strong feelings about it going into Swift 5.

Sorry, my point was that I don't think we can even deprecate the old one. If the pointer you're copying into happens to be an UMP<UInt8>, it'll always pick the old overload even if the new one exists.

Oh, yes of course. Rather than deprecation, we may want an attribute that hides declarations from the documentation. I think we have a number of redundant UnsafePointer-related overloads hanging around. I have mixed feelings about hiding anything from the docs, but I've gotten feedback that the docs need to be simplified to be more approachable.

Looks like this was done in Swift 5!