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@swift.org> wrote: > On 22 June 2017 at 02:46, Jon Shier <j...@jonshier.com> wrote: > >> 1 can already be accomplished by moving the custom initializer into an >> extension. >> > > 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. > > Mike > > _______________________________________________ > 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