[swift-evolution] Initializers

[John McCall]

> On Jan 31, 2017, at 3:13 PM, Victor Petrescu <victor.petrescu13 at gmail.com> wrote:
> @John McCall The expense at runtime issue of course. The fact that I need to add one more line would never bother me enough to bother a few hundreds ppl in turn :).

Are you under the impression that the compiler is unable to inline the super.init() call?

John.

> 
> On Tue, Jan 31, 2017 at 9:51 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> On Jan 28, 2017, at 1:07 PM, Victor Petrescu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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.
> 
> What problem are you trying to solve here?  Are you annoyed at having to write super.init() and/or initialize your instance variables instead of having the compiler "do the right thing" automatically, or are you worried that calling super.init() will be a small but unnecessary expense at runtime?  Because these seem like completely different problems that should be addressed in completely different ways.
> 
> John.
> 
>> 
>> 
>> 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170131/ad589319/attachment.html>