Because the initializer here doesn’t take Any, it takes <T>. ~Robert Widmann
> On Oct 3, 2016, at 2:00 PM, Harlan Haskins via swift-evolution > <swift-evolution@swift.org> wrote: > > Unfortunately, Optional-to-Any does not currently hit this case because IIRC > it doesn't promote to Any in an interpolation segment. I tested this with a > ToT build yesterday. > > - Harlan > > On Oct 3, 2016, at 1:57 PM, Joe Groff <jgr...@apple.com > <mailto:jgr...@apple.com>> wrote: > >> 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 <mailto: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 <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > _______________________________________________ > 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
