Proposal: helpers for initializing properties of same name as parameters

There is also a set keyword in the language already, although today its use is limited such that it may still be used as an identifier in non-conflicting contexts.

FWIW, “set” is a context sensitive keyword, not an actual keyword. You can see the list of actual keywords here:

https://github.com/apple/swift/blob/master/include/swift/Parse/Tokens.def

-Chris

···

On Dec 5, 2015, at 6:58 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

-DW

On Dec 5, 2015, at 7:51 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

I don’t believe any more so than for let or var, which this effectively is a complement for.

There is no Let or Var type in the standard library, but there is a Set type. “Set” has many meanings, and some of them are relatively likely to be used as parameter keywords.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org> wrote:

> On Dec 6, 2015, at 7:41 AM, Matthew Johnson <matthew@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution