[swift-evolution] Proposal: Deprecate optionals in string interpolation

[Charlie Monroe]

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 <clattner at apple.com> wrote:
> 
> 
>> On May 23, 2016, at 12:12 PM, Charlie Monroe via swift-evolution <swift-evolution at 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