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> 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> 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 >> >> I've posted the current draft below. >> >> Thanks, >> Harlan Haskins >> >> Disallow Optionals in String Interpolation Segments >> >> Proposal: SE-NNNN >> Authors: Harlan Haskins, Julio Carrettoni, Robert Widmann >> Review Manager: TBD >> Status: Awaiting revie >> 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 >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> 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). >> >> 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
