Re: [swift-evolution] Extending init checks for property initialization

> On Apr 29, 2016, at 3:00 AM, Vladimir.S wrote: > > Can't see any significant extra overhead because of implicity unwrapped > property for your code. Could you clarify? It's probably not significant in UI code, but if you’re writing something that’ll be accessed a 100k or

Re: [swift-evolution] Extending init checks for property initialization

This is probably the best pattern to deal with this, since there are a number of ugly problems to deal with if passing an incomplete object around. initializers exist with a lot of special case rules around self because they are reusing the term for something that is actually not yet self, but

Re: [swift-evolution] Extending init checks for property initialization

'defer' in this example means something different than 'defer' as used in Swift today. I would expect a 'defer init()' to be called immediately before the main initializer goes out of scope, like how a defer block works today, but this defer init() must be called when the main initializer first

Re: [swift-evolution] Extending init checks for property initialization

Agreed. The static option is definitely better. But I think a deferred option would be that much more elegant. > On Apr 30, 2016, at 11:30 AM, Basem Emara wrote: > > Hey Hooman, that’s very elegant. I didn’t think of it like that and will > definitely use, thx! > >

Re: [swift-evolution] Extending init checks for property initialization

Hey Hooman, that’s very elegant. I didn’t think of it like that and will definitely use, thx! Though wouldn’t “defer init()” take it a step further: 1) reduce redundant boilerplate 2) prevent forgetting/bugs and 3) smaller memory allocation footprint? It also fits well with the existing Swift

Re: [swift-evolution] Extending init checks for property initialization

Besides the ages old designated initializer pattern that is already suggested (having a few designated initializers and a bunch of convenience initializers), this is how I have been dealing with this since Swift 1.0: import UIKit import AVFoundation class SomeViewController: UIViewController {

Re: [swift-evolution] Extending init checks for property initialization

> On Apr 28, 2016, at 5:49 PM, David Sweeris via swift-evolution > wrote: > > >> On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolution >> wrote: >> >> I think I like this idea. It is clear that it is init() and 'defer' says >>

Re: [swift-evolution] Extending init checks for property initialization

Why not use the Designated Initializers and Convenience Initializers ? private var videoPlayer: AVPlayer private var videoPlayerLayer: AVPlayerLayer required

Re: [swift-evolution] Extending init checks for property initialization

On 29.04.2016 2:21, Howard Lovatt via swift-evolution wrote: 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

Re: [swift-evolution] Extending init checks for property initialization

Can't see any significant extra overhead because of implicity unwrapped property for your code. Could you clarify? As for "going away" - as I understand, just ImplicitlyUnwrappedOptional type itself will be removed, but not the "implicitly unwrapped" feature: "Appending ! to the type of a

Re: [swift-evolution] Extending init checks for property initialization

Eh, “going away” might be too strong… They’re changing a lot. There’s still the extra overhead though. > On Apr 28, 2016, at 7:49 PM, David Sweeris via swift-evolution > wrote: > > >> On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolution >>

Re: [swift-evolution] Extending init checks for property initialization

> On Apr 28, 2016, at 11:50 AM, Vladimir.S via swift-evolution > wrote: > > I think I like this idea. It is clear that it is init() and 'defer' says that > it is called at the end of each init. IMO we need exactly some kind of 'init' > as only in init we can set

Re: [swift-evolution] Extending init checks for property initialization

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

Re: [swift-evolution] Extending init checks for property initialization

Good point about unwrapped optionals, but there's no compiler checks to make sure they get initialized. The "defer init" solves the same problem that "defer" within functions resolved. There's no need to duplicate the function call in every init, or forget to call one as new initializers are

Re: [swift-evolution] Extending init checks for property initialization

I think I like this idea. It is clear that it is init() and 'defer' says that it is called at the end of each init. IMO we need exactly some kind of 'init' as only in init we can set un-initialized stored properties. But, why implicitly unwrapped optionals are not solution here? I.e. private

Re: [swift-evolution] Extending init checks for property initialization

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

[swift-evolution] Extending init checks for property initialization

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: