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