[swift-evolution] Initializers

Tue Jan 31 05:52:11 CST 2017

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 at 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 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.
>
>
> 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
> 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/55375f08/attachment.html>