[swift-evolution] Proposal: helpers for initializing properties of same name as parameters

[Tal Atlas]

I greatly appreciate the feedback from those working directly with the
language. Having read though the other proposals I would like to return to
my original proposal, as it seems to have the greatest flexibility and
simplicity from an api perspective. The most frequent pain point with
current initializers are structs with more than a few private stored
properties, the amount of boilerplate is rather annoying. The other benefit
is it gives the writer direct control over what the external api for the
given object is for each specific initializer. I”m not married to the
`init(self.var: Type)` syntax, but would be sad if any solution didn’t stem
from a similar sort of idea.

On Sun, Dec 6, 2015 at 6:02 PM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Dec 6, 2015, at 7:41 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
> >
> > Thanks for chiming in on this thread.  I definitely understand the
> desire to wait on features like this until post-Swfit 3 and possibly
> post-hygienic macros as well.
> >
> > I would add to your list of memberwise initializer deficiencies the fact
> that it is “all or nothing”.  I’m wondering what you think of generalizing
> our “utterance” of the memberwise initializer in a way that allows the
> flexibility for the initializer itself to handle initialization of some of
> the members while allowing the compiler to generate the implementation for
> other members.  I described one idea for doing this in a post last night
> where I described an @initializable member attribute.  I’m not tied to that
> specific solution, but I do think it is highly desirable to have
> complier-generated memberwise initialization that is more flexible than an
> “all or nothing” solution.  What are your thoughts?
>
> That would be great of course, but it depends on the details.  We’d need
> someone to make a specific proposal to hash out whether and how it can work.
>
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/2d4af16c/attachment.html>