4

Reading the documentation and this answer, I see that I can initialize a Unicode character in either of the following ways:

let narrowNonBreakingSpace: Character = "\u{202f}"
let narrowNonBreakingSpace = "\u{202f}"

As I understand, the second one would actually be a String. And unlike Java, both of them use double quotes (and not single quotes for characters). I've seen several examples, though, where the second form (without Character) is used even though the variable is only holding a single character. Is that people just being lazy or forgetting to write Character? Or does Swift take care of all the details and I don't need to bother with it? If I know I have a constant that contains only a single Unicode value, should I always use Character?

Community
  • 1
  • 1
Suragch
  • 484,302
  • 314
  • 1,365
  • 1,393
  • I don't understand the question. String and Character are different types. If you need a string then create a string (with 0, 1, or more characters). If you need a character then create a character. – Martin R Jun 22 '15 at 15:06
  • So any time I need a Character I should always specify it explicitly with `Character`, not leave it to the compiler to infer, correct? Is there a performance difference between the two forms? – Suragch Jun 22 '15 at 15:19

2 Answers2

5

When a type isn't specified, Swift will create a String instance out of a string literal when creating a variable or constant, no matter the length. Since Strings are so prevalent in Swift and Cocoa/Foundation methods, you should just use that unless you have a specific need for a Character—otherwise you'll just need to convert to String every time you need to use it.

Nate Cook
  • 92,417
  • 32
  • 217
  • 178
  • I guess I'm trying to understand what a "specific need" for a `Character` would be if I can just let it be a String anyway. I like your answer because it makes for easier programming. I'm just worried about performance issues when there is lots of Unicode text processing involved (comparing Characters, lookups in Dictionaries, etc.). – Suragch Jun 22 '15 at 15:29
  • You might never run into a specific need, unless you're writing a routine that truly is individually looking at the characters in a string. Re: performance, my blanket advice with Swift is to use the defaults and leave the optimizations to the compiler unless you've proved there's an actual problem. – Nate Cook Jun 22 '15 at 20:08
-2

The Swift compiler will infer the type of the string to actually be character in the second case. Adding : Character is therefor not really needed. In this case I would add it though because it's easy to mistakenly assume that this Character is a String and another developer might try to treat it as such. However, the compiler would throw errors because of that since it inferred the type of this String to not be a String but a Character.

So in my opinion adding Character is not a matter of being lazy or forgetting it, it's a matter of trusting the compiler to correctly infer the type of this constant en to rely on the compiler throwing the correct error whenever I try to use this constant wrong.

Swift's compiler basically takes care of all the details and it doesn't really matter if you add Character, the compiler will (should) take care of it.

donnywals
  • 7,241
  • 1
  • 19
  • 27
  • 2
    This is wrong or at least misleading. The second line `let narrowNonBreakingSpace = "\u{202f}"` creates a String and not a Character. The compiler does not infer the type to be a character in that statement. – Martin R Jun 22 '15 at 15:08
  • 2
    Thanks, I was convinced that this was how it works since both statements output a nonbreaking space, I kind of expected that if `let narrowNonBreakingSpace = "\u{202f}"` was a string it would output the literal string. Today I Learned I guess :) – donnywals Jun 22 '15 at 15:30