[swift-evolution] a few initializer proposals
xiaodi.wu at gmail.com
Thu Jun 22 17:20:57 CDT 2017
These issues which you have raised have been discussed thoroughly on this
list some time ago. It was distilled into a very well written proposal,
SE-0018, that was evaluated and deferred. I would recommend that you and
all people who are interested in this topic review the initial pitch and
the subsequent discussions that took place.
At the conclusion of that process, any improvements for memberwise
initialization were deemed out of scope for Swift 3. Subsequently, all
sugar was out of scope for Swift 4 phase 1 and deemed to be extremely low
priority for Swift 4 phase 2. Whether the topic will be in scope again is
an open question.
The summary of the core team's decision is unusually long and
extraordinarily enlightening. The issues about this feature being out of
scope are discussed as "meta-points," and an extensive amount of text
explains the thought process behind that conclusion. Beyond that, however,
the decision also explores a truly remarkable set of possible solutions to
the underlying issue, and it raises very interesting (non-meta) points that
would have to be carefully considered before any revised proposal.
On Thu, Jun 22, 2017 at 16:14 Mike Kluev via swift-evolution <
swift-evolution at swift.org> wrote:
> On 22 June 2017 at 02:46, Jon Shier <jon at jonshier.com> wrote:
>> 1 can already be accomplished by moving the custom initializer into an
> it can indeed. although if you need to create an extension just for this
> purpose it feels like a workaround, takes more lines and is less obvious,
> imho. plus if #3 is accepted (the same construct for classes) it would be
> more consistent to have it in structs as well.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution