[swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments
kevin at sb.org
Mon Oct 3 19:49:53 CDT 2016
I assume you meant that as a reply to me?
The problem is twofold:
1. Printing the value without adornment, or "nil" for nil, is a very
common thing to want to do and we shouldn't have to write code like
`\(x.map(String.init(describing:)) ?? "nil")` to accomplish it.
2. Due to the changes made to IUOs, if you use a IUO in a string
interpolation, previously it would print as desired (either the value
or the string `"nil"`) but now it prints as Optional (e.g. with the
On Mon, Oct 3, 2016, at 05:43 PM, Robert Widmann via swift-evolution wrote:
> Under our proposal you can return to the old semantics of printing
> nil with an explicit optional cast - one which we will offer to
> insert for you.
> Otherwise if you actually intend for a default value that value would
> have type Int, not String. Under the current regime if you want to
> print something custom the for nil the way you've got it now you're
> going to have to go through the reflecting initializer anyway so I
> don't see a problem here.
> ~Robert Widmann
> 2016/10/03 19:25、Charlie Monroe via swift-evolution <swift-
> evolution at swift.org> のメッセージ:
>> I've already suggested this quite some time back and was told that
>> this doesn't need to go through evolution. It's filed here:
>> Unfortunately, I haven't had time to look into it myself and I'm
>> unlikely to have the time anytime soon...
>>> On Oct 3, 2016, at 7:52 PM, 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:
>>> I've posted the current draft below.
>>> Harlan Haskins
>>> Disallow Optionals in String Interpolation Segments
>>> * Proposal: SE-NNNN
>>> * Authors: Harlan Haskins, Julio Carrettoni, Robert
>>> * Review Manager: TBD
>>> * Status: Awaiting revie
>>> 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
>>> *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
>>> * 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
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution