> 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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
