[swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

[Joe Groff]

We now emit a warning whenever an optional is used as an Any. I disagree that this should be an error, but it seems reasonable to warn (if we don't already thanks to the 'Any' warning).

-Joe

> On Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hey all,
> 
> Julio Carrettoni, Robert Widmann, and I have been working on a proposal to mitigate something that's burned us all since Swift 1. We'd love some feedback!
> 
> It's available here: https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd>
> 
> I've posted the current draft below.
> 
> Thanks,
> Harlan Haskins
> 
> Disallow Optionals in String Interpolation Segments
> 
> Proposal: SE-NNNN <https://gist.github.com/harlanhaskins/NNNN-filename.md>
> Authors: Harlan Haskins <https://github.com/harlanhaskins>, Julio Carrettoni <https://github.com/Julioacarrettoni>, Robert Widmann <https://github.com/CodaFi>
> Review Manager: TBD
> Status: Awaiting revie
>  <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#introduction>Introduction
> 
> Swift developers frequently use string interpolation as a convenient, concise syntax for interweaving variable values with strings. The interpolation machinery, however, has surprising behavior in one specific case: Optional<T>. If a user puts an optional value into a string interpolation segment, it will insert either "Optional("value")" or "nil" in the resulting string. Neither of these is particularly desirable, so we propose a warning and fix-it to surface solutions to these potential mistakes.
> 
> Swift-evolution thread: Discussion thread topic for that proposal <https://lists.swift.org/pipermail/swift-evolution/>
>  <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#motivation>Motivation
> 
> The Swift Programming Language defines string interpolation segments as "a way to construct a new String value from a mix of constants, variables, literals, and expressions". There is one type that runs counter to this definition: Optional. The .none case in particular is used to indicate the absence of a value. Moreover, its inclusion in interpolation segments leads to the dreaded "nil" in output that is often fed to UI elements. Even barring that, interpolating a non-nil optional value yields "Optional("value")", a result that is not useful even in logged output.
> 
> Given that the Optional type is never fit for display to the end user, and can often be a surprising find in the console, we propose that requesting an Optional's debug description be an explicit act. This proposal now requires a warning when using an expression of Optional type within a string interpolation segment.
> 
>  <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#proposed-solution>Proposed solution
> 
> The user will be warned after attempting to use an expression with type Optional<T> in a string interpolation segment. They will then be offered a fixit suggesting they explicitly request the debugDescription of the Optional value instead.
> 
>  <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#detailed-design>Detailed design
> 
> Semantic analysis currently does not do much but guarantee the well-formedness of expressions in interpolation segments. These are then fed directly to String.init(stringInterpolationSegment:) and are run through the runtime reflection system to generate a description. Semantic analysis will be tweaked to inspect the result of solving an interpolation segment for an Optional and will offer a fixit in that case.
> 
>  <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#impact-on-existing-code>Impact on existing code
> 
> As this is a warning, code written before this proposal will continue to compile and run with the same semantics as before. Authors of code that makes use of this unsafe pattern will be offered a migration path to the safer, more explicit form.
> 
>  <https://gist.github.com/harlanhaskins/63b7343e7fe4e5f4c6cfbe9413a98fdd#alternatives-considered>Alternatives considered
> 
> A fixit that suggests a default value be inserted would be entirely appropriate (following the style of the fixit introduced in SE-0140 <https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md>).
> 
> Forbidding this pattern by hard error would make this proposal a breaking change that is out of scope for this stage of Swift's development.
> 
> A fixit that introduces a force-unwrapping would technically work as well, however it would be fixing a dangerous operation with yet another dangerous operation.
> 
> 
> 
> Sent from my iPad
> _______________________________________________
> 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/20161003/fb724e4c/attachment.html>