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

Reply via email to