<div dir="ltr">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:<br><br>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').<br>This means my B class would become something like this:<br><br>class B:A {<br> exp override init() {<br> x = 2;<br> }<br>}<br><br>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.<br><br>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.<br><br>3. Regarding the 3 points made by Jaded Geller:<br> - Safety (see point 1.)<br> - 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)?<br> - 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).<br> <br>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?<br><br>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.<br>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.<br><br>P.S. Sorry for any grammatical errors and thank you for your time.<br><br>Have a great day,<br>Petrescu Victor<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 30, 2017 at 10:36 PM, Robert Widmann <span dir="ltr"><<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>This seems to contradict Swift’s goal of being <a href="https://swift.org/about/" target="_blank">safe by default</a>, no? It would make me incredibly uncomfortable if there were a backdoor in DI, even if that backdoor emitted traps when it fails.</div><br><div><blockquote type="cite"><div>On Jan 28, 2017, at 1:07 PM, Victor Petrescu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_6366567572854909533Apple-interchange-newline"><div><div dir="ltr"><div><div><div><div><div><div><div>Hello,<br><br></div>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.<br><br></div>Sidenote: If this is not the correct mailing list for this can you please redirect me to the right place?<br><br></div>Consider the following 2 classes and code:<br><br></div>class A {<br></div> var x:Int<br><br></div> init() {<br></div> x = 1<br><div> }<br><div><div>}<br><br></div><div>class B : A {<br></div><div> override init() {<br></div><div> super.init() // Swift FORCES this call<br></div><div> x = 2<br></div><div> }<br></div><div>}<br><br></div><div>var a:B<br></div><div>for i in 0...99999999 {<br></div><div> a = B() // Whatever... some code that inits B.<br></div><div>}<br></div><div><br></div><div>This results in 99999999 x = 1 then 99999999 x = 2... the x = 1 being totally useless in this particular case.<br><br></div><div>In this case, if you don't make the super init you get a compile error.<br><br></div><div><b>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.<br><br></b></div><div>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.<br><br></div><div>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.<br><br><br></div><div>P.S. Please excuse any grammatical errors... English is not my first language.<br></div><div><br></div><div>Thank you for your time and have a great day,<br></div><div>Petrescu Victor<br></div></div></div></div>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></blockquote></div><br></div>