I also thought at most of the issues presented before making the
suggestion. Let me adress each one (in the order of how I see their
importance) and explain my point of view:
1. Most inportant - safety: As Robert Widmann (and others) pointed out
swift is safe by default. And I love that about swift. Is the main reason I
migrated towards it. Still, I highlight the "by default" part. I am
suggesting adding a little keyword to explicit say that the developer
doesn't want to call the parent init() (let's say that keyword is 'exp').
This means my B class would become something like this:
class B:A {
exp override init() {
x = 2;
}
}
This way swift still remains safe by default. A developer can still be sure
that everything is safe unless he explicitly choosed to wave that safety
for a little performance boost. Imo, that should be the developers choice.
2. Private variables: Well... those are a pain. David Sweeris idea of a
flag sounds nice to me, but I don't know if there would be any undesired
consequences for this. Basically if that flag is not set and 'exp' a
compile error is shown.
3. Regarding the 3 points made by Jaded Geller:
- Safety (see point 1.)
- Compiler optimization to eliminate duplicate: If this is
possible/exists it would/is totally solving the issue in an elegant way. In
my test it appeared it does not exist. Is it possible to make compiler skip
the x = 1 line (personally I can't see how but maybe someone can prove me
wrong - I would really love that because it would be exactly what I need)?
- Regarding the workaround proposed: Yes, it works in the simple
particular case I exposed, but in real life cases is not practical (imagine
you have 30 variables).
4. Joe Groff says there is already a backdoor of sorts ("There already is a
backdoor of sorts. This is one of the intended use cases for
implicitly-unwrapped optionals. If you don't want to be hassled by DI,
declare a property as T! type, and it will be implicitly initialized to
nil, and trap if you try to use it as an unwrapped T without initializing
it first."): I'm assuming by T you mean generics. If that is true that may
already solve the problem but... generics are a new concept for me (first
time I really encountered and used them is now, in swift) but to my
understanding their role is to deal with cases you don't know the type. Can
you please show how to use this to work around the posted issue?
Sidenote: There may be another workaround using optionals (Joe Groff answer
made it pop in my mind) but... I know the type and value for the variable,
it is not optional or nil. Unwrapping each time someone needs it does not
look like the best solution to me.
Sidenote: Is not that strange to have a superclass to initialize to
something then the subclass to anothe value (I had multiple real cases like
this where it was helpful - example carFuel a few years back -> most cars
work on gas, but then electric cars started to raise; it is helpful to have
130 brands of cars that extends from a general brand that have carFuel as
'gas', and Tesla (for example) that inits it to 'electric'). The example I
originally posted, and the one posted in this sidenote where intentionally
oversimplified to expose the case.
P.S. Sorry for any grammatical errors and thank you for your time.
Have a great day,
Petrescu Victor
···
On Mon, Jan 30, 2017 at 10:36 PM, Robert Widmann <devteam.codafi@gmail.com> wrote:
This seems to contradict Swift’s goal of being safe by default
<https://swift.org/about/>, no? It would make me incredibly
uncomfortable if there were a backdoor in DI, even if that backdoor emitted
traps when it fails.
On Jan 28, 2017, at 1:07 PM, Victor Petrescu via swift-evolution < > swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
:)