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

Kevin Ballard kevin at sb.org
Mon Oct 3 20:54:42 CDT 2016 

On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote:
>
>> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution <swift-
>> evolution at swift.org> wrote:
>>
>> 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.
>
> My point is before you were unable to do this without the ‘uglyness’
> presented here anyway [you would have gotten “Optional(“value”)”], so
> I don’t see the point of raising this concern.  If you want the old
> behavior, just ask for it with an explicit cast or
> `.debugDescription`.

This proposal was done because the current behavior of Optionals in
string interpolation isn't very useful for most people. You're proposing
banning it outright (with an escape hatch to recover the current
behavior). I'm saying that, since it isn't very useful for most people,
instead of banning it we could make it useful.

-Kevin

>> 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).
>
> IUOs are not in the scope for this proposal, but I get your point.
>
>>
>> -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
>>
>> _______________________________________________
>> 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/c631626b/attachment.html>

More information about the swift-evolution mailing list