-3

We define variable as optional using "?", for example: 

var name : String?

and then throughout the program we get variable name value using "?", for example:

print (name?)

Is there anyway we can get rid of "?" each time when unwrapping optional variable.

Termininja
  • 6,620
  • 12
  • 48
  • 49
Bilawal Liaqat
  • 178
  • 4
  • [See here](http://stackoverflow.com/a/36360605/2976878) for a (fairly) complete guide on how to deal with Optionals. Sounds like you want Optional Binding. – Hamish Apr 07 '16 at 08:00
  • Yes, don't use optionals too much - unwrap as soon as possible and use non-optionals later. – Sulthan Apr 07 '16 at 08:03
  • 1
    there was a deleted answer here suggesting `var name : String!` which imo is not a bad option depending on when this variable is initialised. if its part of the init process then by all means use it, but if you arent sure when it would be initialised then stick with the `?` and unwrap appropriately – Fonix Apr 07 '16 at 08:06
  • 2
    Consider to use non-optional variables as much as possible. Especially regarding `String` and scalar values like `Int` it's often sufficient to treat `empty string` or `0` as *no value*. – vadian Apr 07 '16 at 08:29
  • `print(name?)` does not compile (`error: '?' must be followed by a call, member lookup, or subscript`), you probably meant `print(name!)`. – Valentin Apr 07 '16 at 11:36

3 Answers3

2

You need to use conditional binding to avoid it.

For example:

var name : String?
name = "Hello world"

if let unwrappedName = name as? String
{
   // Now unwrappedName isn't optional
}

Basically, unwrappedName will be String AKA not optional.

But it really all depends what you are trying to achieve, if you know for sure that name will never be nil I'd suggest using implicitly unwrapped:

var name : String!

But using implicitly unwrapped suggest that name could be nil thus the conditional binding need to be checked again - it all depends on how sure are you that the variable will never be nil.

OhadM
  • 4,687
  • 1
  • 47
  • 57
  • 2
    You can't know for sure that the value will never be nil. What if you or a colleague changes the code in a month. General rule: Never user implicit unwrapped optionals. – dasdom Apr 07 '16 at 08:09
  • 1
    You can't throw a statement like "Never use implicit unwrapped optionals", they exist for a reason - this reason. Please backup your statement with a reference. Anyhow, I don't agree with you because it is all app/algorithm dependent and if your colleague changes the code and suddenly the app crashes it is his fault and NOT the implicit unwrapped optionals. – OhadM Apr 07 '16 at 08:12
  • 2
    If you know a variable can *never* be nil, then surely the best course of action would be to make it non-optional to *begin* with? If it's value depends on an instance state - then use a lazy variable, or give it a placeholder value. Really there's a very small number of cases where an implicitly unwrapped optional is actually required. – Hamish Apr 07 '16 at 08:16
  • @originaluser2, please read the question again: "throughout the program we get variable name value " this means that only during runtime they assign a value so you can't make it String since it has no value yet. Of course, you can always make it String and assign "" to it. But why not using the implicitly unwrapped optional which doesn't need the assignment of an empty string.. – OhadM Apr 07 '16 at 08:20
  • 2
    @OhadM OP is taking about *accessing* the value there, not assigning it. The gripe I have with implicitly unwrapped optionals, its they're a form of type un-safety. You are *able* to assign nil to them at runtime - the compiler isn't able to stop you from doing so, as it's still an optional. You can also assign other optionals to it - and again the compiler can't stop you. Doing either of these can result in a crash at runtime - therefore they're inherently unsafe. – Hamish Apr 07 '16 at 08:31
  • @originaluser2, this is why implicitly unwrapped optional is the developer responsibility. – OhadM Apr 07 '16 at 08:47
  • 1
    @OhadM Sure, but as a developer, it's often better to let the compiler know *exactly* what you're doing - so it can stop you if it's a bad idea. If a value can *never* be nil, then define it as non-optional. That way you don't have to worry about whether your app could crash every time you use that variable. – Hamish Apr 07 '16 at 08:58
  • Again, it is all depend on what you are trying to achieve and what are your demands. – OhadM Apr 07 '16 at 09:53
  • @OhadM You don't need the `as String?` part in your unwrapping since the compiler already knows you are working with a `String?`. – Valentin Apr 07 '16 at 12:34
  • @Valentin, This is correct but it's for the sake of the example - readability. – OhadM Apr 07 '16 at 12:44
1

You should rather unwrap the optional using if let and guard let.

dasdom
  • 13,975
  • 2
  • 47
  • 58
1

Use Implicitly Unwrapped Optionals for avoid using ? every time but make sure your variable must have value at time using it

let someString:String!;

when you get value of someString 

someString = "this is the string"

and access someString without "?"

Tarun Seera
  • 4,212
  • 4
  • 27
  • 41