[swift-evolution] Pitch: Modify the meaning of IBOutlet to remove the ! from the type

[Krystof Vasa]

Within this proposal, would it be still possible to test the variable against nil? 

If yes, then it'd be very confusing, since you'd have a variable declared as non-optional, but you'd be comparing it to nil.

If no, this is not correct since the instance can be executing code before the nib file is loaded and the UI elements connected. Which is again a weird situation where you have variables that when accessed, the app crashes, but you can't check if it's valid.

The @IBOutlet variables are pretty much just dynamic vars with an extra annotation so that IB knows that they can be connected in the UI. This would be causing the annotation to change the type of the variable which is a matter discussed in another thread here as well.

Krystof

> On May 18, 2016, at 3:22 PM, Daniel Steinberg via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I would like to propose we modify the meaning of @IBOutlet in light of the accepted proposal SE-0054 Abolish ImplicitlyUnwrappedOptional type. I think this fits in with the current Swift 3 goals.
> 
> Currently we use “var” and “!” when we declare an outlet like this:
> 
> @IBOutlet weak var myLabel: UILabel!
> 
> The “!” in the declaration allows us to use the outlet like this without unwrapping it
> 
> myLabel.text = “Hello"
> 
> We use “var” and “UILabel!" because myLabel starts its life out as nil and does not have a value until the connection is made. i.e. myLabel must be an optional if it accepts nil and the type is UILabel! instead of UILabel? so that we don’t have to unwrap it each time we use it.
> 
> If we break the connection to the UILabel instance we crash at runtime for attempting to unwrap nil.
> 
> Given this, I propose that we be able to write
> 
> @IBOutlet weak let myLabel: UILabel
> 
> In this case @IBOutlet has a meaning somewhat similar to lazy - it’s not that myLabel doesn’t exist until we first call it, but @IBOutlet indicates that myLabel should exist before we call it. 
> 
> If the connection isn’t made and myLabel doesn’t exist, we should crash as we do now. If the connection is not made in the nib or storyboard, this will crash at development time. 
> 
> This removes a case in which we use var - not because we want to change the value of a property but because of a detail in the tooling.
> 
> This change also removes a case in which we use an Optional again for a detail in lifecycle and tooling.
> 
> Best,
> 
> Daniel
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution