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
