Enforce initialization in more contexts / everywhere / up to debate

[Araq]

Nim should enforce explicit initialization in all code paths rather than relying on default(T). This helps the optimizer, makes code easier to read/follow and can prevent minor bugs in the program logic. It also means that nil can only creep into your program when you write it explicitly, a good compromise given that the not nil annotation doesn't work well with generic containers like Table.

This will also fit the new move semantics perfectly well as we can use the same algorithm that detects "variable used before initialization" for "variable used after move".

[cooldome]

While it is always to implementor to decide what is right way to implement the feature,

Here is an idea how it can be potentially done and allow smooth transition for existing code:
Give a user control over default(T) value. User can choose zero default (backwards compatible), particular default value (say "" for a string or empty table) or no default value (compiler starts complaining that the object needs to be initialized explicitly).

[Clyybber]

I think this should be possible before we enforce initialization:

type
  someobject = object
    somefield: sometype = somedefaultvalue
    ...

I heard it is planned?

[Araq]

I heard it is planned?

That's exactly what I had in mind too. :-)

[yglukhov]

I think this requires a hell lot more thought to deserve any milestone tag. Currently I fail to see a lot of value in enforcing explicit init.

• How does this help optimizer? The value will be initialized upon var definition no matter what. In fact, implicit init will give the optimizer more options to initialize it later upon first usage, in case that matters.
• How does this help a generic container like Table? getOrDefault will return the default, it can't know how else to init the returned value.
• How should an object be constructed?

var myObj = SomeThirdPartyObj(a: 123, b: 456) # What happens when third party adds another field?

Arguments for implicit init:

1. by var init:

var a: array[10, int] # Explicit init doesn't make sense
getSomeInts(a)

2. Conditional init:

var maxCoord: int # Explicit init doesn't make sense
if horizontal:
  doSomeComplexLayout()
  applyHorizontalConstraints()
  someMoreComplexStuff()
  maxCoord = x + width
else:
  doSomethingElse()
  applyVerticalConstraints()
  someMoreComplexStuff()
  maxCoord = y + height

[andreaferretti]

Also, it may be convenient to initialize an object piecewise. Something like

type Foo = object
  a: int
  b: string

proc makeMyFoo(): ref Foo =
  new result
  result.a = 3
  result.b = "hi"

I used this pattern a lot in linalg in generic procedures to abstract over the precise type of result (it may be a static or dynamic matrix, 32-bit or 64-bit and so on) and I get a lot of ProveInit warnings. I would not turn them into errors until the compiler is able to analyze this pattern and check that result is in fact correctly initialized.

I don't rely on this pattern as extensively in Neo, but here is an example where I need it.

If the compiler became smart enough to analzye this kind of control flow, then it would make more sense to enforce initialization

Zig also requires all variables to be initialized manually.
For cases such as these - https://github.com/nim-lang/Nim/issues/7917#issuecomment-394326942 Arguments for implicit init, it uses undefined to leave a value unspecified, i.e. var x: int = undefined.
Maybe something like that can be added to nim as well.

[cooldome]

I think we should not label this RFC asEnforce initialization, now everyone is confused and thinking everything is going to change.

Would rather say "Allow users to enforce explicit initialization for certain types and control over default value"

[andreaferretti]

@cooldome That title seems to describe your proposal, rather than the one by @Araq

It also means that nil can only creep into your program when you write it explicitly

It is a +1 for me because of this.

[Araq]

Just for the record

Conditional init:

would continue to work under my proposal.

[dom96]

I think this should be possible before we enforce initialization:

type
 Someobject = object
   somefield: Sometype = somedefaultvalue
   ...

I like this, but we should concretely discuss what is and isn't allowed. For example, can somedefaultvalue be a global variable? a value returned from a function? or just a concrete constructor or literal? Will I be able to get the old behaviour by writing default(Sometype)?

How will generics interact with this feature?

---

👍 to @yglukhov's observations.

Also, the json.to macro currently cannot use the explicit init syntax. Be aware of this when implementing this, the Nim AST may need to be made more flexible for such cases (check out the sort of code that to generates to see what I mean).

[dom96]

Seems you guys have been beat by a couple of years: https://github.com/nim-lang/Nim/issues/3250 :)

[CodeDoes]

initialized attributes could be defined as simply as

type Foo = object
  attr: int = 5

Being rewriten to

type Foo = object
  attr: int
defaultFoo = Foo(attr: 5)

then checking defaultFoo value everytime an object is constructed.

nillable attributes could be designated with

attr: int?

Nil should not be comparable to zero