[swift-evolution] [Pitch] Unifying init parameters with properties

Vladimir.S svabox at gmail.com
Thu Apr 14 11:53:00 CDT 2016


So I suggest to discuss some "middle" solution: not too complex, but that 
will improve our live. I believe this (in subject) proposal don't require a 
lot of changes in Swift, it seems more like sugar

Compiler "just" can replace

init (self.a: Int, self.b: String) {
   //...
}

to

init (a: Int, b: String) {
   self.a = a
   self.b = b
   //...
}

Yes, I understand that we can actually omit types for init(as each prop has 
its own type already) :

init (self.a, self.b, someOther: String) {
//...
}

But I'm afraid this brokes Swift parser a lot(so probably it is complex to 
implement this) and IMO init becomes not explicit on types of parameters 
when just looking at it(we need to go to each property to find this out). 
So I personally -1 for such skipping of types.

On 14.04.2016 18:41, Tino Heth via swift-evolution wrote:
> There has been a long debate about something similar:
> [Proposal Draft] Flexible memberwise initialization
> <http://article.gmane.org/gmane.comp.lang.swift.evolution/727>
>
> Afair there has been a general agreement that the current boilerplate is
> ugly, but all suggested alternatives had flaws as well (and init is already
> a complicated topic).
> I'm quite sure a variant of your idea has been discussed, but didn't turn
> into a formal proposal.
> Getting rid of a third of the boilerplate wouldn't be bad, and imho some
> additional characters could be saved if you skip the type declarations
> (this would also make it easier to refactor).
> The linked proposal had less boilerplate, but much higher complexity.
>
> Tino
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


More information about the swift-evolution mailing list