[swift-evolution] Extending init checks for property initialization

[Howard Lovatt]

I like the `defer init` idea but suggest you have to explicitly call it at
the end of all the other non-convenience `init`s. The advantage of an
explicit call are two fold:

  1. It is obvious what is happening
  2. You can pass arguments

On Friday, 29 April 2016, Basem Emara via swift-evolution <
swift-evolution at swift.org> wrote:

> I see what you’re saying and the forced optionals is pretty inconvenient.
>
> As far as syntax, how about more of a “deferred” init that gets triggered
> regardless like this:
>
> defer init() {
>     // Always gets called no matter what designated init triggers
> }
>
> > On Apr 27, 2016, at 5:52 PM, Shannon Potter via swift-evolution <
> swift-evolution at swift.org <javascript:;>> wrote:
> >
> > Consider a relatively-common init pattern:
> >
> > class SomeViewController: UIViewController {
> >
> >    // MARK: Properties
> >
> >    private var videoPlayer: AVPlayer
> >    private var videoPlayerLayer: AVPlayerLayer
> >
> >    // MARK: - Object Lifecycle
> >
> >    override init(nibName: String?, bundle nibBundle: NSBundle?) {
> >        super.init(nibName: nibName, bundle: nibBundle)
> >
> >        commonInitialization()
> >    }
> >
> >    required init?(coder decoder: NSCoder) {
> >        super.init(coder: decoder)
> >
> >        commonInitialization()
> >    }
> >
> >    private func commonInitialization() {
> >        videoPlayer = AVPlayer(...)
> >        videoPlayerLayer = AVPlayerLayer(player: videoPlayer)
> >    }
> >
> > }
> >
> > This does not work. Both properties are non-optional, and the compiler
> complains that they are not initialized in either init method. It seems
> rather common to want a single point of contact regarding object
> initialization, regardless of the path taken to initialize that object.
> Ideally, objects could all be funneled to one designated initializer, but
> this isn’t always the case.
> >
> > What are people’s thoughts about either a specialized function that is
> always called at the very end of each object’s lifecycle OR some sort of
> attribute for a function that hints that the compiler should follow it if
> called in an init function to check for property initialization?
> >
> > func commonInit() {
> >
> > }
> >
> > or
> >
> > @extend_init private func commonInitialization() {
> >
> > }
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <javascript:;>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160429/af325b50/attachment.html>