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

[Tony Allevato]

Similarly, a weak reference cannot be non-optional. I would be
uncomfortable with an attribute changing that behavior. Having a
non-optional field become nil or crash behind the scenes discards the
safety of the Swift type system.

There are legitimate situations where a class might have unused outlets as
well, where you would want an optional (`?`) type; for example, you could
have an iPad nib that has additional views that aren't present in an iPhone
nib, but both share the same view controller. In that case, you would want
to have some of those outlets still be optional. (Your pitch may not
prevent that behavior, but it's worth pointing out as a use case.)


On Wed, May 18, 2016 at 6:42 AM Vladimir.S via swift-evolution <
swift-evolution at swift.org> wrote:

> Correct me if I'm wrong, but `weak` reference can not be `let` just by
> definition: at some point in time such reference *can* become nil.
>
> On 18.05.2016 16:22, Daniel Steinberg via swift-evolution 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
> >
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160518/d3a14af6/attachment.html>