[swift-evolution] [Pitch] Unifying init parameters with properties
Vladimir.S
svabox at gmail.com
Thu Apr 14 11:17:01 CDT 2016
Don't think idea with super.bar etc in init is good, as we should
explicitly call super.init() with needed parameters.
So, I see this in such a way:
init(self.foo: String, bar: String, baz: Int)
super.init(bar: bar, baz: baz)
...
}
The only way we can specify values for super.init in our init() is if
special form of init will be introduced like:
init(self.foo: String, super.bar: String, super.baz: Int); //<-- see this
semicolon
i.e. "emtpy" init. Probably it will be good to have such "empty" init, but
the more important to have feature to init our own props in init header.
So +1 for props in init parameters, unsure about "empty" inits to support
super.props.
On 14.04.2016 18:40, Ross O'Brien wrote:
> (re-added swift-evolution)
>
> I would think so. It's an abbreviation of a given init function, so you
> would call other self.init() or super.init() functions normally. Saves on
> complication.
>
>
> Alternatively, perhaps you could do this:
>
> init(self.foo: String, super.bar: String, super.baz: Int)
>
> as an abbreviation of
> init(foo: String, bar: String, baz: Int)
> {
> self.foo = foo
> super.init(bar: bar, baz: baz)
> }
>
> I think this would probably require allowing parameters to stay
> re-orderable, though (in case super's init is "init(baz: Int, bar:
String)" ).
>
>
>
> On Thu, Apr 14, 2016 at 4:29 PM, Vladimir.S wrote:
>
> +1. This will make our life easier, it is clear and explicit about the
> result.
>
> I assume that there must be a constrain : you can use in init(...) only
> props introduced in the same class, not in parent class.
>
>
> On 14.04.2016 17:32, Ross O'Brien via swift-evolution wrote:
>
> init(self.foo: String, self.bar: String, self.baz: Int)
>
> {
>
> barCount = bar.characters.count
>
> }
>
> }
>
>
> Less boilerplate, more focus on the properties which need to be
> generated.
>
> Thoughts?
>
>
More information about the swift-evolution
mailing list