Strong +1 for the (at least) warning in case of optional in string
interpolation.
Actually I think `Optional(something)` is a form of text representation for
*debugging only*, not for 'production'. It is clear, that by default we
need text representation for 'production', so it is logical for me that
optional in string interpolation should return text without `Optional(..)`.
Probably this means that optional should not have default .description for
`production`, but just debugDescription for debugging.
So, for production you'll need to have:
let newURL = NSURL(string: "http://apple.com\(originalURL.path!)/help")
(or use ?? etc)
for debugging:
let newURL = NSURL(string:
"http://apple.com\(originalURL.path.debugDescription)/help")
On 19.05.2016 10:39, Krystof Vasa via swift-evolution wrote:
Consider the following example:
let originalURL: NSURL = NSURL(string: "http://apple.com/iphone";)!
let newURL = NSURL(string: "http://apple.com\(originalURL.path)/help")
What's the newURL? Nil, because it was being inited with
http://apple.comOptional(/iphone)/help
<http://apple.comoptional%28/iphone%29/help>
Since the path property is optional.
Which is not something you figure out until runtime, wondering why the URL
is nil. This is very annoying when you run into this issue repeatedly on
several occasions because you forget to unwrap the value.
*This* is IMHO an undesired and unexpected behavior.
If interpolating optionals did become a warning, you'd immediately know
about a potential bug: you don't check if path != nil.
BTW if you still want the original behavior of printing
Optional(my string value),
you can still write
"http://apple.com\(originalURL.path.debugDescription)/help"
which invokes debugDescription on the Optional, not the String (since there
is no "?"), and you get the original value anyway. And this could be the
Fix-It for it as well to maintain original behavior.
Krystof
On May 19, 2016, at 9:28 AM, Dan Appel <dan.appe...@gmail.com
<mailto:dan.appe...@gmail.com>> wrote:
You know what's worse than seeing "Optional(my string value)" in a label?
Seeing "nil". When the optional is there, it is made clear to the
developer that the string they are showing /can be nil/. However, if you
hide that from the users you are less likely to unwrap that optional and
hence more likely to show the user "nil". This behavior really goes
against some of the core ideas of Swift - you want your code to be
expressive but not abstract away potentially useful information.
On Thu, May 19, 2016 at 12:24 AM David Waite
<da...@alkaline-solutions.com <mailto:da...@alkaline-solutions.com>> wrote:
Making string interpolation reject just optional (at compile time)
when it doesn’t reject any other type sounds tricky to express.
What if instead Optional just didn’t decorate the wrapped value,
outputting either the inner value or “nil” in these cases?
The debugDescription could remain "Optional(data)" style.
-DW
On May 19, 2016, at 12:52 AM, Valentin via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
From what I understand of this thread, the argument here is that
directly using an optional in a string interpolation is almost never
what you really want to do (except mainly for debugging purposes)
but you wouldn't see this mistake until much later at runtime.
And I feel like one of Swift goals is to enable us, imperfect human
creatures, to detect as many problems or mistakes as possible long
before runtime.
On 19 mai 2016, at 00:56, Dan Appel via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1.
Optional(foo) better depicts the actual type (it's an options
string, after all). If you're not happy with it, just use the nil
coalescing operator such as "\(foo ?? "")". This is from the same
series of proposals as implicit casting - there are reasons it's
done the way it is.
On Wed, May 18, 2016 at 3:49 PM Jacob Bandes-Storch via
swift-evolution <swift-evolution@swift.org
<mailto:swift-evolution@swift.org>> wrote:
+1, personally I have taken to using `x+"str"+y` instead of
`"\(x)str\(y)"`, if x/y are strings, so I can get a
compile-time error if I do this accidentally.
But I do see the appeal of being able to print("the data:
\(data)") for simple use cases. Didn't someone earlier propose
some modifiers/labels like "\(describing: x)" ?
On Wed, May 18, 2016 at 11:50 AM, 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dan Appel
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
