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

[Charlie Monroe]

> 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.

Only if you returned `Any?` - which then Optional<Any>, anyway.

> The actual definition of debugDescription is discouraged from being called by user code. This method also only coincidentally provides the identical text as string interpolation today. Are you proposing to change the standard library documentation to say that users should be calling debugDescription in this scenario, and change optional to define what its implementation of debugDescription returns?

What about adding .description (i.e. comply to CustomStringConvertible) and calling .description instead? I'll update the proposal to match this.

> If I have a type which I don’t want used in String interpolation, I would like to mark it as giving a warning. Examples would be a Result type for representing success or error from a function call, or a future type to represent a task dispatched to another thread that may or may not have finished and returned a result yet. Do you propose a way for me to have the compiler warn if I accidentally have these types used in string interpolation as well, or do I only benefit from optional as a special case.

I'd prefer to leave the Optional as a special case handled by the language, but you can deprecate interpolation for custom types yourself - see below.

> And finally, I can have my own type which implements StringInterpolationConvertible. Examples might be 
> - LocalizableString type which maps the provided string to correct user output through a localization table
> - DebugString for debug logging that uses CustomDebugStringConvertible when available to represent types
> - an HtmlEscapedString which deals with making values that don’t implement the HtmlEscaped protocol HTML-safe, including Strings
> 
> How would I get the optional usage defined for String type interpolation for these cases. DebugString would like to represent optionals as today, LocalizableString would like to capture optionals so that it can switch to a specific internationalized message in this case, and HtmlEscapedString would like the same behavior you are proposing for String.

The deprecation doesn't necessarily need to be handled by the compiler itself, but can be enforced by the following code:

extension String {
	
	@available(*, deprecated, message="Interpolation of optionals is deprecated.")
	init<T>(stringInterpolationSegment segment: Optional<T>) {
		// fatalError()
	}
	
}


With this kind of implementation, you get the warnings, however, without the compiler support you won't get the Fix-It for adding .description - I'm not sure the renamed= part of the attribute can be abused to do this, but I don't think it can be.

And in a similar fashion, you can deprecate the Optional or any other kind on your other strings and keep them on DebugString.

Charlie

> -DW
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160523/963c9a52/attachment.html>