Flexible memberwise initialization #76
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
||
| 2. Sometimes mutable properties that have a sensible default value are simply default-initialized and the same post-initialization configuration strategy is employed when the default value is not correct for the intended use. This results in an instance which may pass through several states that are incorrect *for the intended use* before it is correctly initialized for its intended use. | ||
|
|
||
| Underlying this problem is the fact initialization scales with M x N complexity (M members, N initializers). We need as much help from the compiler as we can get! |
There was a problem hiding this comment.
Minor: Shouldn't this be the following?
“Underlying this problem is the fact that initialization scales...”
|
Looks good, please squash it into one patch and I'll commit it! |
added example for lazy properties correct typos and small omissions added link to Swift Evolution thread fix initialzier typo Significant rewrite The programmer and implementation models have received major revisions to improve clarity and simplify implementation. Third draft Remove changes to existing initialization rules. Add @default attribute enabling let properties to supply a default value for their initialization parameter. Move @nomemberwise to future enhancement. Fix mistakes in examples and other typos. typo fix Refined to focus on core functionality 1. Moved @default to future enhancement. 2. Moved initializer chaining to future enhancement. 3. Clarified impact on existing code and the implicit memberwise initializer. Specify Chris Lattner as review manager Typo fixes, clarifications, and slight redundancy reduction. Fix typos and fill out access control alternatives The primary change is a fleshing out of the rationale for the access control design choice made in this proposal under the alternative "Allow parameters to be synthesized for properties with a lower access level than the initializer". Access control refinements and typo fix 1. Clarify eligibility of properties with distinct setter access control. 2. Refine access control of implicitly generated memberwise initializer. 3. Add future enhancement to allow distinct access control for memberwise initialization eligibility.
anandabits
force-pushed
the
flexible-memberwise-initialization
branch
from
800b5b5
to
a26e09b
Compare
|
Thanks Chris. I believe I have squashed them properly now! I made a few further refinements to the interaction with access control you might want to review:
|
lattner
added a commit
that referenced
this pull request
Dec 28, 2015
…tion Flexible memberwise initialization
|
Awesome! We'll open the discussion period early next year, most likely the week of Jan 4th. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.