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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
