[swift-evolution] [Proposal] Make `didSet` also available for `let` property, or something new such as `didInit`

shengjia wang wangshengjia01 at gmail.com
Wed Dec 23 11:39:10 CST 2015


You are saying: *"Because you can probably just put most of that code at
the end of your initialiser"*. I see.. and this proposal is exactly about
how to avoid this situation.

I'm saying it would be neat if we can band some side effects once we set a
`let` property. Example:

    let view: UIView {

        didSet {

            view.background = UIColor.blackColor()




    let scrollView: UIScrollView {

        willSet {

            scrollView.removeObserver(self, forKeyPath: "contentOffset")


        didSet {

            scrollView.addObserver(self, forKeyPath: "contentOffset",
options: .New, context: nil)



    init(targetScrollView: UIScrollView) {

        view = UIView()

        scrollView = targetScrollView


        // if we could put them into property observing ...

        // view.background = UIColor.blackColor()

        // view.translatesAutoresizingMaskIntoConstraints

        // scrollView.addObserver(self, forKeyPath: "contentOffset",
options:.New, context: nil)

        // ...


We can extract the "setup property" step from init method and separate them
for all different properties just after the property be initialised.
Otherwise, we have to either mix them into the init method or change `let`
to `var`. Both are doable but not ideal in my opinion.

By the way, the principal of this idea is similar to another approach for
IBOutlet property
<https://twitter.com/jesse_squires/status/626264940450480128> :

Use *didSet* on your IBOutlets to configure views instead of cramming code
> into viewDidLoad. Much cleaner. Still called only once.

- Victor Wang

On Wed, Dec 23, 2015 at 5:07 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:

> willSet and didSet are currently not even called from the init method.
> This also goes counter to the current property behaviors proposal (didGet
> and didSet would become part of that) because behaviors aren't planned for
> let properties.
> You're saying you want it to happen as soon as it was set, but do you
> really need it "as soon as that" or can you afford to wait a little bit?
> Because you can probably just put most of that code at the end of your
> initializer, where it's guaranteed that the property has been set.
> Félix
> Le 23 déc. 2015 à 10:22:46, shengjia wang via swift-evolution <
> swift-evolution at swift.org> a écrit :
> Since swift v1.2, we can initialize `let` property in `init()` instead of
> being forced to give a value when declare it. This is great !
> But every time I run into the case such as the example below:
> let view: UIView {
>   didSet {
>     /**
>      * This time, `view` did set ( a.k.a initialized in case of `let`
> property), so I want to bind some other actions just after, such as
> `setBackgroundColor`. But actually I can't, compiler will complain that
> `let` declaration can not be observing properties. So I have to either move
> all these "actions" to `init()` or change `view` to a `var` property which
> is not necessary at all.
>      */
>   }
> }
> Actually in swift, I think it's quite commun issue that people run into a
> large `init()` method. This approach could make it way better in most cases.
> So, I'm wondering why not make `didSet` also available for `let` property,
> or maybe even better to add new keyword such as "didInit" which only get
> called for first set.
> - Victor Wang
> _______________________________________________
> 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/20151223/33fef72b/attachment.html>

More information about the swift-evolution mailing list