It seems to me that A should provide an `init(x: Int = 1) { self.x = x }`
initializer in such case so B may call `super.init(x: 2)`. This initializer
could even be made internal if necessary, but it honestly seems weird for a
superclass to default initialize to a certain value and a subclass to default
initialize to another.
Regardless, I definitely don’t think introducing unsafely is the right choice.
If anything, there ought to be a compiler optimization (if there isn’t one
already) that’ll eliminate these duplicate assignments—and I would bet there is
if `super.init()` can be inlined.
> On Jan 28, 2017, at 10:07 AM, Victor Petrescu via swift-evolution
> <[email protected]> wrote:
>
> Hello,
>
> My name is Victor, been a developer (C, delphi, php, java, js) for the last
> 10 years or so and lately I had the chance to try swift. I have a
> suggestion/question regarding initializers.
>
> Sidenote: If this is not the correct mailing list for this can you please
> redirect me to the right place?
>
> Consider the following 2 classes and code:
>
> class A {
> var x:Int
>
> init() {
> x = 1
> }
> }
>
> class B : A {
> override init() {
> super.init() // Swift FORCES this call
> x = 2
> }
> }
>
> var a:B
> for i in 0...99999999 {
> a = B() // Whatever... some code that inits B.
> }
>
> This results in 99999999 x = 1 then 99999999 x = 2... the x = 1 being totally
> useless in this particular case.
>
> In this case, if you don't make the super init you get a compile error.
>
> Now... I see the use of this. It ensure that all members are initialized. For
> example if A had a private variable (another strange choice here with what
> private means in swift but I haven't thought on it yet so... maybe is a cool
> choice), the B init could not initialize it. I also understand that the cases
> when you need this minor performance gain are rather rare (but they do still
> exist). So I guess the choice for the super.init() had that reasoning.
>
> Still... my suggestion would be to give a warning, maybe force a key word
> before the init (like iKnowWhatImDoing init() {}), THEN in case vars are
> still not inited give a runtime error (afaik Objective C for example gives a
> warning). That ensures everything is ok and also allows programmers that have
> strange cases to treat them accordingly.
>
> Anyway... that would be my suggestion. Maybe this was discussed before
> also... If this was discussed before can you please point me to the
> discussion? I like to understand the choices for the tools I use.
>
>
> P.S. Please excuse any grammatical errors... English is not my first language.
>
> Thank you for your time and have a great day,
> Petrescu Victor
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
