I've jotted up a proposal here:
https://gist.github.com/charlieMonroe/82e1519dd2b57029f69bc7abe99d7385
Please let me know if there are any comments to it.
Charlie
> On May 20, 2016, at 9:11 AM, Krystof Vasa via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> Four questions:
>> 1. If I was printing a protocol type that Optional supports, such as Any,
>> would I get a warning?
>
> This was my bad, I wrote an incorrect example,
> print("http://apple.com\(myURL.path) <http://apple.com/(myurl.path)>") was
> what I meant - which will print
>
> http://apple.comOptional(/iphone/) <http://apple.comoptional(/iphone/)>.
>
> Putting an optional directly into print(_:) should be fine with no warning.
> Only within the string interpolation.
>
>> 2. I believe debugDescription is discouraged from being called directly
>> [from CustomDebugStringConvertible docs]. Perhaps String(reflecting: )
>> instead, although such debug description behavior could cause different
>> results if you were expecting this fixit to apply to Any types.
>
> This is not invoked on the value within the Optional, but directly *on* the
> Optional. As declared here (part of Swift):
>
> extension Optional : CustomDebugStringConvertible {
> /// A textual representation of `self`, suitable for debugging.
> public var debugDescription: String { get }
> }
>
> Example:
>
> let stringOptional: String? = "Hello"
>
> // Notice no ? is used - the optional is not unwrapped
> stringOptional.debugDescription // Optional(Hello)
>
> // Unwrapping the optional
> stringOptional!.debugDescription // Hello
>
> Not sure what would be the impact of making Optional CustomStringConvertible
> (i.e. instead of using debugDescription, one would use just description).
>
>> 3. How would I have the ability to opt into this behavior for my own types
>> (such as Result or Future)?
>> 4. How would I opt in/out of this behavior for my own
>> StringInterpolationConvertible implementations?
>
> This is not about customizing the interpolation but about warning the user
> when using optionals in string interpolation to prevent from such mistakes as
> above with the URL. This is more common than one would think and sometimes is
> hard to spot. I'm sorry if I misunderstood you questions.
>
>>
>> -DW
>>
>>>
>>> I'm not saying *removing* the current behavior, but adding a warning for
>>> this - you'd get the same result ignoring the warning and applying the
>>> Fix-It, but you'd have control over this.
>>>
>>>> On May 20, 2016, at 6:48 AM, Dan Appel via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>
>>>> >google for swift print optional stackoverflow. I think that kind of
>>>> >speaks for itself.
>>>>
>>>> I think this is actually an example of why the current behavior is a good
>>>> thing. I did just google that and the top comment of the first result
>>>> explains what an optional is. That is very good and encourages beginners
>>>> to understand how optionals work under the hood. If you hide that from
>>>> them, they will only be even more confused when they see just the string
>>>> "nil" pop up when it previously was showing the correct value.
>>>>
>>>> On Thu, May 19, 2016 at 9:36 PM Krystof Vasa via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> BTW - google for swift print optional stackoverflow. I think that kind of
>>>> speaks for itself.
>>>>
>>>> > On May 19, 2016, at 6:07 PM, Jeremy Pereira via swift-evolution
>>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> >
>>>> > -1
>>>> >
>>>> > This seems to me like crippling string interpolation just because
>>>> > sometimes we make mistakes. 99% of the time, if I interpolate an
>>>> > optional, it’s because I want it that way. I don’t want to have to put
>>>> > up with a warning or write the same boilerplate 99% of the time just to
>>>> > flag up the 1% more easily. Sorry.
>>>> >
>>>> >> On 18 May 2016, at 19:50, Krystof Vasa via swift-evolution
>>>> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> >>
>>>> >> The string interpolation is one of the strong sides of Swift, but also
>>>> >> one of its weaknesses.
>>>> >>
>>>> >> It has happened to me more than once that I've used the interpolation
>>>> >> with an optional by mistake and the result is then far from the
>>>> >> expected result.
>>>> >>
>>>> >> This happened mostly before Swift 2.0's guard expression, but has
>>>> >> happened since as well.
>>>> >>
>>>> >> The user will seldomly want to really get the output
>>>> >> "Optional(something)", but is almost always expecting just "something".
>>>> >> I believe this should be addressed by a warning to force the user to
>>>> >> check the expression to prevent unwanted results. If you indeed want
>>>> >> the output of an optional, it's almost always better to use the ??
>>>> >> operator and supply a null value placeholder, e.g. "\(myOptional ??
>>>> >> "<<none>>")", or use myOptional.debugDescription - which is a valid
>>>> >> expression that will always return a non-optional value to force the
>>>> >> current behavior.
>>>> >>
>>>> >> Krystof
>>>> >>
>>>> >> _______________________________________________
>>>> >> swift-evolution mailing list
>>>> >> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >
>>>> > _______________________________________________
>>>> > swift-evolution mailing list
>>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> --
>>>> Dan Appel
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
