I'm not a great fan of the
@noImplicitCopy naming or syntax, and would definitely love to come up with something better. The reason
@noImplicitCopy doesn't affect ABI is that it's an artificial local constraint, that ties the compiler's hands from using its normal ARC and value semantics tricks to manage memory for a particular value, whereas whether a type even has a "copy" operation at all to stick in the value witness table is a fundamental ABI concern. I think we will however want to be able to allow some degree of retrofitting noncopyable type support into the ABI; the basic calling conventions for passing a noncopyable value don't change, and it would be useful to be able to replace standard library APIs with implementations that don't rely on copying, and then expose them as not requiring copyability in a new version of the OS.
The "bolted-on"-ness is maybe a little bit intentional, since we still expect a good majority of Swift code will remain oblivious to copy controls and still be fine with automatic memory management, so we're trying to keep noncopyable types and the various controls on copy behavior on the "progressive" side of "progressive disclosure". I like the idea of a Rust-style
: ?Copyable constraint remover; that seems like a nice unifying syntax for opting types out of providing copyability and stopping generics from requiring it. Is
var x: ?Copyable = copyableValue() too weird as a way of spelling
@noImplicitCopy on an individual binding?