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
