Definitely right about that, the implementation
<https://github.com/CodaFi/swift/commit/43a582ef0fb108369f3df955f617b77b71cbd45e#diff-9124ea1eb6021a3c7323d7a07fd85c1eR2409>
took all of 10 minutes after extending the OptionalToAnyCoercionWalker. If
you’ve got any comments, please let me know there.
~Robert Widmann
> On Oct 3, 2016, at 4:06 PM, Mark Lacey <mark.la...@apple.com> wrote:
>
>>
>> On Oct 3, 2016, at 11:26 AM, Joe Groff via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>>> On Oct 3, 2016, at 11:02 AM, Robert Widmann <devteam.cod...@gmail.com>
>>> wrote:
>>>
>>> Because the initializer here doesn’t take Any, it takes <T>.
>>
>> I think there's a case to be made to generalize the 'Any' warning to
>> Optional implicitly being deduced as a type variable binding in any
>> unconstrained context. What exactly constitutes 'implicit' and
>> 'unconstrained' is up for debate, though, and probably needs some
>> experimentation to figure out what feels good. For instance, explicitly
>> constructing an optional is a signal the optionality intentional.
>> Potentially, having multiple Optional parameters binding the same type
>> variable also increases the likelihood it's intended, for example:
>>
>> func foo<T>(x: T, y: T) {}
>>
>> var x: Int? = 1
>> var y: Int = 2
>> foo(x, y) // One Optional isn't unwrapped, forcing the other to promote.
>> Maybe a mistake?
>> var z: Int? = 3
>> foo(x, z) // Two T parameters are Optional. Probably intentional?
>>
>> Regardless of whether there's a more general principle we can base a warning
>> on, string interpolation and String(describing:) are common enough pitfalls
>> that they may just deserve special case treatment.
>
> I think string interpolation could be handled pretty easily with a warning by
> extending the existing warning for Any. We just need to look at interpolation
> expressions and if any of the segments are optional-typed emit a warning
> unless they are explicitly casted to the optional type. The fixit can suggest
> explicit casting or using the debugDescription.
>
> I’m not sure we really need an evolution proposal for that.
>
> As for the more general topic of trickiness around optional injection into
> unconstrained generics: Yes, we should review that at some point as well. I
> recall seeing at least one concrete complaint about surprising behavior
> resulting from doing this in generic functions, but I cannot find the bug at
> the moment.
>
> Mark
>
>
>>
>> -Joe
>>
>>> ~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> 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> 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
>>>>>> • 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
>>>>>
>>>> _______________________________________________
>>>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
