Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-3956] In Swift 3.1, assigning a let protocol's var in init generates an error #46541

Open
swift-ci opened this issue Feb 14, 2017 · 3 comments
Open

Comments

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Feb 14, 2017

Previous ID SR-3956
Radar None
Original Reporter benasher44 (JIRA User)
Type Bug
Environment

macOS Sierra 10.12.3
Xcode 8.2.1 (App Store version)
Swift 3.1 snapshot: 3.1-DEVELOPMENT-SNAPSHOT-2017-02-11-a

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, 3.1Regression
Assignee None
Priority Medium

md5: 7117b5bd4615c0cd1a5a3e3e77ecfedd

Issue Description:

The following code works fine in Swift 3 (3.0.2) but generates an error in Swift 3.1:

protocol SampleDelegate: class {}

protocol Sample {
    weak var delegate: SampleDelegate? { get set }
}

class SampleA: Sample {
    weak var delegate: SampleDelegate?
}

class Sampler: SampleDelegate {
    let s: Sample = SampleA()

    init() {
        self.s.delegate = self
    }
}

Here is the generated error:

test.swift:15:25: error: cannot perform mutating operation: 'self.s' is a 'let' constant
self.s.delegate = self
^
test.swift:12:5: note: change 'let' to 'var' to make it mutable
let s: Sample = SampleA()
^~~
var

I can see why this was allowed before, since the let constant doesn't need to be guaranteed to be fully initialized until after init has completed.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Feb 15, 2017

Hm. @jckarter, what do you think?

benasher44 (JIRA User), note that if you make Sample class-constrained as well the problem goes away. As written, the error is arguably correct, since setting anything on a let property, ever, would be invalid if it might be a value type.

@swift-ci
Copy link
Collaborator Author

@swift-ci swift-ci commented Feb 15, 2017

Comment by Ben A (JIRA)

That makes sense![]( I agree the fix is easy to do on our end, but I thought it'd be worth reporting anyway since this does seem to be different in Swift 3.1 compared to Swift 3.0. Thanks)

@belkadan
Copy link
Contributor

@belkadan belkadan commented Feb 15, 2017

Oh, yes, we definitely want to know about it. :-) Thanks for reporting.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants