I’m still unclear what the answers to my questions below would be. I’ll restate them below.
>>> 1. If I was printing a protocol type that Optional supports, such as Any, >>> would I get a warning? Since this may have been misunderstood, let me phrase it a different way. 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? >>> 2. I believe debugDescription is discouraged from being called directly >>> [from CustomDebugStringConvertible docs]. Perhaps String(reflecting: ) >>> instead, although such debug description behavior could cause different >>> results if you were expecting this fixit to apply to Any types. 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? >>> 3. How would I have the ability to opt into this behavior for my own types >>> (such as Result or Future)? >>> 4. How would I opt in/out of this behavior for my own >>> StringInterpolationConvertible implementations? >> >> This is not about customizing the interpolation but about warning the user >> when using optionals in string interpolation to prevent from such mistakes >> as above with the URL. This is more common than one would think and >> sometimes is hard to spot. I'm sorry if I misunderstood you questions. 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. 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. -DW
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
