[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