<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 &quot;by default&quot; part. I am suggesting adding a little keyword to explicit say that the developer doesn&#39;t want to call the parent init() (let&#39;s say that keyword is &#39;exp&#39;).<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&#39;t know if there would be any undesired consequences for this. Basically if that flag is not set and &#39;exp&#39; 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&#39;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 (&quot;There already is a backdoor of sorts. This is one of the intended use cases for implicitly-unwrapped optionals. If you don&#39;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.&quot;): I&#39;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&#39;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 -&gt; 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 &#39;gas&#39;, and Tesla (for example) that inits it to &#39;electric&#39;). 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">&lt;<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>&gt;</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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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&#39;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&#39;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>