I've pretty much rewritten the propsal
(https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385) to use
casting to `as Any` instead of the formally suggested `.debugDescription` or
`.description` to silence the warning.
It also includes `Uninterpolable` protocol that `Optional` conforms to and you
can hence deprecate interpolation of your own types.
Questions, however:
- `Uninterpolable` seems too restrictive a name - it's not that the type
*can't* be used for interpolation, but it is discouraged from being used for
interpolation. Any ideas for better names?
- Should the deprecation of interpolation of `Uninterpolable` be declared:
- on `String`, thus allowing custom `StringInterpolationConvertible`
classes to still use the `Uninterpolable` for interpolation, or
- as an extension of `StringInterpolationConvertible`, thus disallowing
interpolation of all `Uninterpolable` types.
I personally prefer the latter as you always can force the interpolation using
`as Any`. Thoughts?
Charlie
> On May 24, 2016, at 1:23 AM, Chris Lattner <clatt...@apple.com> wrote:
>
>
>> On May 23, 2016, at 12:12 PM, Charlie Monroe via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>> If the URL path property was defined not to return ‘String?' but to return
>>> ‘Any’ (which can of course hold an Optional just like it can hold any other
>>> type) what would the proposed compiler behavior be?
>>
>> No warning. Since you cast Optional to Any, no warning can even be issued
>> since that will eventually be determined during runtime, there's not much
>> the compiler can do here.
>
> I agree. It is important for optionals to be string literal convertible in
> generic situations as well as when boxed in an existential like Any. That
> said, emitting a warning when the compiler knows statically that it has an
> optional makes a lot of sense.
>
> -Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
