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

[Charlie Monroe]

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 <svabox at gmail.com> 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>