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

[Tal Atlas]

This syntax is confusing with that of defining the external keyword for the
parameter.

On Sat, Dec 5, 2015 at 9:24 PM David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> A possible syntax, then:
>
>         init(set name:String, set score:Int) { }
>
> set would be a fourth parameter modifier alongside let, var, and inout -
> only valid on initializers (not as useful and likely confusing in other
> contexts). The local name has to match a parameter on the type. Like
> let/var (but unlike inout) usage of ‘set’ on a initializer parameter does
> not affect the caller or prototype conformance.
>
> -DW
>
> > On Dec 5, 2015, at 3:31 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> Did you read through by reply to the original proposal?  I believe it
> provides the convenience you're looking for here while still allowing for
> the flexibility to avoid boilerplate in initializers that do more than just
> set properties.
> >
> > I did, and I didn’t really like it. One of the syntaxes it proposed was
> strange and ad-hoc; the other was a fairly arbitrary overloading of
> parentheses, although it doesn’t actually conflict with anything since you
> can’t overload “calling parentheses” on a non-function.
> >
> > It’s important to ensure that, when the implementation evolves, you can
> replace the initializer transparently. For instance, suppose I have a type
> which represents a player in a game. It uses a stored property called
> `points`:
>
> _______________________________________________
> 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/88c0be93/attachment.html>