<commit_before># Flexible Memberwise Initialization

* Proposal: [SE-0018](https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initializers.md)
* Author(s): [<NAME>](https://github.com/anandabits)
* Status: **Rejected**
* Review manager: <NAME>

## Introduction

The Swift compiler is currently able to generate a memberwise initializer for use in some circumstances, however there are currently many limitations to this.  This proposal builds on the idea of a compiler generated memberwise initializer, making the capability available to any initializer that opts in.

Swift-evolution thread: [Proposal Draft: flexible memberwise initialization](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/003902.html)

## Motivation

When designing initializers for a type we are currently faced with the unfortunate fact that the more flexibility we wish to offer users the more boilerplate we are required to write and maintain.  We usually end up with more boilerplate and less flexibility than desired.  There have been various strategies employed to mitigate this problem, including:

1. Sometimes properties that should be immutable are made mutable and a potentially unsafe ad-hoc two-phase initialization pattern is employed where an instance is initialized and then configured immediately afterwards.  This allows the developer to avoid including boilerplate in every initializer that would otherwise be required to initialize immutable properties.

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 that initialization scales with M x N complexity (M members, N initializers).  We need as much help from the compiler as we can get!

Flexible and concise initialization for both type authors and consumers will encourages using immutability where possible and removes the need for boilerplate from the concerns one must consider when designing the intializers for a type.

Quoting [<NAME>](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000518.html):

	The default memberwise initializer behavior of Swift has at least these deficiencies (IMO):
	1) Defining a custom init in a struct disables the memberwise initializer, and there is no easy way to get it back.
	2) Access control + the memberwise init often requires you to implement it yourself.
	3) We don’t get memberwise inits for classes.
	4) var properties with default initializers should have their parameter to the synthesized initializer defaulted.
	5) lazy properties with memberwise initializers have problems (the memberwise init eagerly touches it).
<commit_msg>add link to rejection rationale.<commit_after># Flexible Memberwise Initialization

* Proposal: [SE-0018](https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initializers.md)
* Author(s): [<NAME>](https://github.com/anandabits)
* Status: [**Rejected**](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006469.html)
* Review manager: <NAME>

## Introduction

The Swift compiler is currently able to generate a memberwise initializer for use in some circumstances, however there are currently many limitations to this.  This proposal builds on the idea of a compiler generated memberwise initializer, making the capability available to any initializer that opts in.

Swift-evolution thread: [Proposal Draft: flexible memberwise initialization](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/003902.html)

## Motivation

When designing initializers for a type we are currently faced with the unfortunate fact that the more flexibility we wish to offer users the more boilerplate we are required to write and maintain.  We usually end up with more boilerplate and less flexibility than desired.  There have been various strategies employed to mitigate this problem, including:

1. Sometimes properties that should be immutable are made mutable and a potentially unsafe ad-hoc two-phase initialization pattern is employed where an instance is initialized and then configured immediately afterwards.  This allows the developer to avoid including boilerplate in every initializer that would otherwise be required to initialize immutable properties.

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 that initialization scales with M x N complexity (M members, N initializers).  We need as much help from the compiler as we can get!

Flexible and concise initialization for both type authors and consumers will encourages using immutability where possible and removes the need for boilerplate from the concerns one must consider when designing the intializers for a type.

Quoting [<NAME>](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000518.html):

	The default memberwise initializer behavior of Swift has at least these deficiencies (IMO):
	1) Defining a custom init in a struct disables the memberwise initializer, and there is no easy way to get it back.
	2) Access control + the memberwise init often requires you to implement it yourself.
	3) We don’t get memberwise inits for classes.
	4) var properties with default initializers should have their parameter to the synthesized initializer defaulted.
	5) lazy properties with memberwise initializers have problems (the memberwise init eagerly touches it).

{'fraction_non_alphanumeric': 0.04949843775694787, 'fraction_numerical': 0.0164446637066272, 'mean_word_length': 5.174619289340102, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 9, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2363542', 'n_tokens_mistral': 1514, 'n_tokens_neox': 1370, 'n_words': 774}