Assignment to 'let' constant in defer blocks

Is this a feature or a bug?
class Foo {
    let bar: Int
    init?(someConditionBasedOnInputData: Bool) {
        var localBar: Int = 0
        defer {
            bar = localBar //Cannot assign to property: 'bar' is a 'let' constant
        }
        if someConditionBasedOnInputData {
            return nil
        }
    }
}
It’d be handy to be able to do the assignment upfront in a defer block in cases where there’s both a bunch of validation to do on the input data, and no harm from assigning the interim values to the final values when you’re about to return nil anyway.

- Dave Sweeris

Seems like it should work. Maybe it is a bug that should be reported to SR.

Does this error occur for non-failable initializers?

···

On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:

Is this a feature or a bug?

class Foo {
    let bar: Int
    init?(someConditionBasedOnInputData: Bool) {
        var localBar: Int = 0
        defer {
            bar = localBar //Cannot assign to property: 'bar' is a 'let'
constant
        }
        if someConditionBasedOnInputData {
            return nil
        }
    }
}

It’d be handy to be able to do the assignment upfront in a defer block in
cases where there’s both a bunch of validation to do on the input data, and
no harm from assigning the interim values to the final values when you’re
about to return nil anyway.

- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Is this a feature or a bug?

Low priority bug IMO.

-Chris

···

On Mar 10, 2017, at 9:33 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

class Foo {
    let bar: Int
    init?(someConditionBasedOnInputData: Bool) {
        var localBar: Int = 0
        defer {
            bar = localBar //Cannot assign to property: 'bar' is a 'let' constant
        }
        if someConditionBasedOnInputData {
            return nil
        }
    }
}
It’d be handy to be able to do the assignment upfront in a defer block in cases where there’s both a bunch of validation to do on the input data, and no harm from assigning the interim values to the final values when you’re about to return nil anyway.

- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

How would that work for a subclass, if all properties of a class need to be initialized before the parent's initializer is called?

-Andrew

···

On Mar 11, 2017, at 8:46 AM, Derrick Ho via swift-evolution <swift-evolution@swift.org> wrote:

Seems like it should work. Maybe it is a bug that should be reported to SR.

Does this error occur for non-failable initializers?

On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
Is this a feature or a bug?
class Foo {
    let bar: Int
    init?(someConditionBasedOnInputData: Bool) {
        var localBar: Int = 0
        defer {
            bar = localBar //Cannot assign to property: 'bar' is a 'let' constant
        }
        if someConditionBasedOnInputData {
            return nil
        }
    }
}
It’d be handy to be able to do the assignment upfront in a defer block in cases where there’s both a bunch of validation to do on the input data, and no harm from assigning the interim values to the final values when you’re about to return nil anyway.

- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yep

···

On Mar 11, 2017, at 7:46 AM, Derrick Ho <wh1pch81n@gmail.com> wrote:

Seems like it should work. Maybe it is a bug that should be reported to SR.

Does this error occur for non-failable initializers?

If I was trying to subclass something and add extra instance variables, yeah, I don’t think it would work. I’m not trying to subclass anything in this case, though.

- Dave Sweeris

···

On Mar 11, 2017, at 9:49 AM, andrew@arnopoulos.io wrote:

How would that work for a subclass, if all properties of a class need to be initialized before the parent's initializer is called?

-Andrew

On Mar 11, 2017, at 8:46 AM, Derrick Ho via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Seems like it should work. Maybe it is a bug that should be reported to SR.

Does this error occur for non-failable initializers?
On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Is this a feature or a bug?
class Foo {
    let bar: Int
    init?(someConditionBasedOnInputData: Bool) {
        var localBar: Int = 0
        defer {
            bar = localBar //Cannot assign to property: 'bar' is a 'let' constant
        }
        if someConditionBasedOnInputData {
            return nil
        }
    }
}
It’d be handy to be able to do the assignment upfront in a defer block in cases where there’s both a bunch of validation to do on the input data, and no harm from assigning the interim values to the final values when you’re about to return nil anyway.

Is this a feature or a bug?

Low priority bug IMO.

Agreed.

John.

···

On Mar 11, 2017, at 11:57 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 10, 2017, at 9:33 PM, David Sweeris via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-Chris

class Foo {
    let bar: Int
    init?(someConditionBasedOnInputData: Bool) {
        var localBar: Int = 0
        defer {
            bar = localBar //Cannot assign to property: 'bar' is a 'let' constant
        }
        if someConditionBasedOnInputData {
            return nil
        }
    }
}
It’d be handy to be able to do the assignment upfront in a defer block in cases where there’s both a bunch of validation to do on the input data, and no harm from assigning the interim values to the final values when you’re about to return nil anyway.

- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution