[swift-evolution] Initializers
Victor Petrescu
victor.petrescu13 at gmail.com
Sat Jan 28 12:07:59 CST 2017
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170128/5ad9b535/attachment.html>
More information about the swift-evolution
mailing list