<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Sorry, didn't have time to actually submit the proposal, but it at least gave me some time to think it through a few more times.<div class=""><br class=""></div><div class="">After reconsiderations, I suggest the following:</div><div class=""><br class=""></div><div class="">- deprecation of interpolation of optionals.</div><div class="">- extending the Optional type by:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- <b class="">var detailedDescription: String</b> - which will return the same value as until now: "nil" for nil and "Optional(value)" for .some(_). This is due to .description and .debugDescription's documentation discouraging direct invocation.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- <b class="">func descriptionWithDefaultValue(_ defaultValue: String = "nil") -> String</b> - which would return either the description of the value, or `defaultValue`.</div><div class=""><br class=""></div><div class="">So, when the compiler runs into interpolation of an Optional, it issues a warning with a fix-it, that by default calls .descriptionWithDefaultValue() on the optional.</div><div class=""><br class=""></div><div class="">Person who wants the original behavior can still get it using `.detailedDescription`.</div><div class=""><br class=""></div><div class="">I'll put it into a proper proposal tomorrow.<br class=""><div class=""><br class=""><blockquote type="cite" class="">On May 27, 2016, at 2:23 PM, Vladimir.S <<a href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>> wrote:<br class=""><br class="">I believe the only 'fix' here is to prevent string interpolation for anything that is not base types like String, Integer, Double, Boolean or that is explicitly provides textual(not for debugging) representation.<br class=""><br class="">For all others like function, Optional etc leave only debug string interpolation, when we should explicitly ask "get debgug info text for this item".<br class=""><br class="">I.e. in my opinion we shouldn't be able to do "\(url.lowercased)" or "\(op)" (if `op` is optional).<br class=""><br class="">But, *at least* we need warnings if optional, function or something like this is in string interpolation.<br class=""><br class="">On 27.05.2016 11:17, Charlie Monroe wrote:<br class=""><blockquote type="cite" class="">That's a good point.<br class=""><br class="">I still recommend having "Uninterpolable" protocol which could be then applied on any type. Unfortunately, this would require to introduce some kind of a reflection API on the function type :-/<br class=""><br class="">I'll think about it further today and will try to submit a final version of the proposal.<br class=""><br class=""><blockquote type="cite" class="">On May 27, 2016, at 8:56 AM, Vladimir.S <<a href="mailto:svabox@gmail.com" class="">svabox@gmail.com</a>> wrote:<br class=""><br class="">Just caught another issue with string interpolation:<br class=""><br class="">"File \"\(url.lowercased)\" not found."<br class=""><br class="">I mistyped the `lowercased` without `()` and got:<br class="">File "(Function)" not found.<br class=""><br class="">I believe we need a protection for such situations<br class=""><br class="">On 24.05.2016 13:01, Charlie Monroe via swift-evolution wrote:<br class=""><blockquote type="cite" class="">Hi Nicola, thanks for the feedback.<br class=""><br class=""><blockquote type="cite" class="">I assume you mean "at runtime" here?<br class=""></blockquote><br class="">That's probably my wrong wording. :) The unexpected result is at runtime, but we'd like to catch this at compile time. I've updated it to say<br class=""><br class="">"in order to prevent unexpected results already at compile time" - hopefully that's a clearer wording.<br class=""><br class=""><blockquote type="cite" class="">I think the detailed design needs some more thought. The "Uninterpolable"<br class="">protocol, and suggesting to cast "as Any" in a Fix-it both seem hacks.<br class=""></blockquote><br class="">Originally, the proposal was simply to emit a warning for interpolation of Optionals, but several people made good points:<br class=""><br class="">- there may be other types you may not want to use for interpolation - as mentioned in the proposal, e.g. private data structures that would expose something you want to keep private, various enum values, etc. Which is why I've started thinking about making a protocol that would indicate the type is discouraged being "interpoled". I've thought about this and decided to make a more robust and customizable solution.<br class=""><br class="">An alternative to this would be to use annotations or just drop this customizability completely. But I think with Swift and its protocol-driven development, marking the type with this protocol is the most robust way to go.<br class=""><br class="">- both .description and .debugDescription are mentioned in alternatives for the Fix-It.<br class=""><br class="">"as Any" seemed, however, the cleanest and most robust solution to me, since then the Uninterpolable protocol can be applied to any type without forcing the type to conform to CustomStringConvertible as well. I agree that it's kind of a hack, though.<br class=""><br class=""><blockquote type="cite" class="">I'm not even sure if the general direction of a compile time warning is the<br class="">right one, and if the problem wouldn't be better solved by simply not making<br class="">Optional put "Optional()" around the value in its .description.<br class=""></blockquote><br class="">There are many people oposing this and expecting the Optional() wrap around the value, indicating the actual type. Actually, including me - I agree it can be useful for some types of debugging since in what you wrote further, there'd be no difference between description of [1, 2, 3] (i.e. [Int]) and Optional([1, 2, 3]) (i.e. [Int]?).<br class=""><br class="">There are legitimate usecases where the current behavior is correct, but in most of cases, having an optional in string interpolation will lead either to unnecessary clutter in the log/console or bugs - in which case even "nil" is not correct to be used for the interpolation. Which is the basis for this proposal.<br class=""><br class=""><blockquote type="cite" class="">print("\(o)") // "Optional(1)", why??<br class=""></blockquote><br class="">String has several overloads for the init(stringInterpolationSegment:) initiailizer. Optional falls into the generic <T> category, which will call String(optional) - which most likely uses debugDescription.<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><br class=""></blockquote></blockquote><br class=""><br class=""></blockquote></blockquote><br class=""></div></div></body></html>