That's a good point. 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 :-/
I'll think about it further today and will try to submit a final version of the proposal. > On May 27, 2016, at 8:56 AM, Vladimir.S <[email protected]> wrote: > > Just caught another issue with string interpolation: > > "File \"\(url.lowercased)\" not found." > > I mistyped the `lowercased` without `()` and got: > File "(Function)" not found. > > I believe we need a protection for such situations > > On 24.05.2016 13:01, Charlie Monroe via swift-evolution wrote: >> Hi Nicola, thanks for the feedback. >> >>> I assume you mean "at runtime" here? >> >> 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 >> >> "in order to prevent unexpected results already at compile time" - hopefully >> that's a clearer wording. >> >>> I think the detailed design needs some more thought. The "Uninterpolable" >>> protocol, and suggesting to cast "as Any" in a Fix-it both seem hacks. >> >> Originally, the proposal was simply to emit a warning for interpolation of >> Optionals, but several people made good points: >> >> - 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. >> >> 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. >> >> - both .description and .debugDescription are mentioned in alternatives for >> the Fix-It. >> >> "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. >> >>> I'm not even sure if the general direction of a compile time warning is the >>> right one, and if the problem wouldn't be better solved by simply not making >>> Optional put "Optional()" around the value in its .description. >> >> 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]?). >> >> 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. >> >>> print("\(o)") // "Optional(1)", why?? >> >> 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. >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
