[swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

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
   `"Optional(…)"` wrapper).

-Kevin

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:
>> https://bugs.swift.org/browse/SR-1882
>>
>> 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:
>>> 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[1]
>>>  * Authors: Harlan Haskins[2], Julio Carrettoni[3], Robert
>>>    Widmann[4]
>>>  * 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[5]
>>> 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[6]).

>>>  * 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _________________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Links:

  1. https://gist.github.com/harlanhaskins/NNNN-filename.md
  2. https://github.com/harlanhaskins
  3. https://github.com/Julioacarrettoni
  4. https://github.com/CodaFi
  5. https://lists.swift.org/pipermail/swift-evolution/
  6. https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161003/bc596e9b/attachment.html>