[swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

[Charles Srstka]

I didn’t even know the compiler still supported these implicit conversions. So, +1, I guess.

Charles

> On Mar 23, 2017, at 12:35 AM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Good evening all,
> 
> Attached is the proposal text that came out of a short discussion on Twitter <https://twitter.com/dgregor79/status/844760063663259651> about squashing one more case of implicit conversions in the language.  This proposal seeks to remove the implicit nature of toll-free bridging in favor of an explicit as-cast.  The proposal can also be read as a gist <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f>, and the most up-to-date copy may be found on swift-evolution itself <https://github.com/apple/swift-evolution/pull/655>.
> 
> Cheers,
> 
> ~Robert Widmann
> 
> Explicit Toll-Free Conversions
> 
> Proposal: SE-NNNN <https://gist.github.com/CodaFi/NNNN-filename.md>
> Authors: Robert Widmann <https://github.com/codafi>
> Review Manager: TBD
> Status: Awaiting review
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#introduction>Introduction
> 
> To continue removing further implicit conversions from the language, implicit toll-free bridging should be deprecated in Swift 3 and removed in Swift 4.0.
> 
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#motivation>Motivation
> 
> Swift currently allows implicit conversions between CF types and their toll-free-bridged Objective-C counterparts. This was meant to maintain parity with the feature in Objective-C. However, the presence of implicit conversions is no longer in-line with the expectations of Swift's type system. In addition, advancements in the Clang importer have made interaction with imported CF and Foundation types nearly seamless - obviating the need for this feature in general. For the sake of safety, and in the spirit of continuing the work of SE-0072 <https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md> and facilitating SE-0083 <https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md>, we propose the deprecation and removal of this implicit conversion in favor of an explicit as cast.
> 
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#proposed-solution>Proposed solution
> 
> The implicit conversion between toll-free-bridged types shall be removed. In its place, the user should use explicit ascasts to convert bewteen bridged CF and Objective-C types.
> 
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#detailed-design>Detailed Design
> 
> When in Swift 3 mode, the compiler shall warn when it encounters the need to perform an implicit conversion. At the warning site, it can offer the explicit as cast to the user as a fix-it.
> 
> func nsToCF(_ ns: NSString) -> CFString {  
>   return ns // warning: 'NSString' is not implicitly convertible to 'CFString'; did you mean to use 'as' to explicitly convert?
> }
> 
> func cfToNS(_ cf: CFString) -> NSString { 
>   return cf // warning: 'CFString' is not implicitly convertible to 'NSString'; did you mean to use 'as' to explicitly convert?
> }
> When in Swift 4 mode, the compiler shall no longer perform the implicit conversion and relying on this behavior will be a hard error.
> 
> func nsToCF(_ ns: NSString) -> CFString {  
>   return ns // error: cannot convert return expression of type 'NSString' to return type 'CFString'
> }
> 
> func cfToNS(_ cf: CFString) -> NSString { 
>   return cf // error: cannot convert return expression of type 'CFString' to return type 'NSString'
> }
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#source-compatibility>Source compatibility
> 
> This introduces a source-breaking change that affects consumers of APIs that are explicitly taking or vending instances of bridged CF or Objective-C types. However, recent importer advances have made APIs like this far less numerous. In practice, we expect the source breakage to eludicate places where implicit conversions were accidentally being performed behind the user's back.
> 
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#effect-on-abi-stability>Effect on ABI stability
> 
> This proposal has no effect on the Swift ABI.
> 
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#effect-on-api-resilience>Effect on API resilience
> 
> This proposal has no effect on API resilience.
> 
>  <https://gist.github.com/CodaFi/fc6fa3aac64c4b1deffd1434a37e295f#alternatives-considered>Alternatives considered
> 
> Do nothing and continue to accept this implicit conversion.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170323/d69af417/attachment.html>