[nem-en] Field initializers specification

[Dmitry Ivankov]

For now there are no strict rules for static/instance field initializers.

Examples:
class A{ //related to literals, and to order of inits
static y : int = x + 1; //it's 2
static x : int = 1; //it's 1
}
class A2{ //related to order of inits
static y : double= x + 1; //it's 1
static x : double = 1; //it's 1
}
class B{
static y : int = x + 1; //it's 1
static x : int = y + 1; //it's 2
}
class C{ //access to "this"
 x : object = this.x; //it's null
}

Key questions about field init are:
1) Order of inits?
Possibly one of the following:
- in order of appearence in source, then macro-generated fields in order
of generation
- in order of "visual declaration" (order of macro declared fields depends
on place where macro is used, or on some other thing), i.e. if we apply
macro on method and it declares a field then field is "visually declared"
before/after that method
- by following rule: first field that doesn't use not initialized yet fields
is initialized next (example A2 will work like A)
2) When inits are executed?
2.a) before or after call to base c-tor?
- immediately before any ctor
- immediately before any ctor, which doesn't call other c-tor
- somewhere in c-tor, but before field can be used
- somewhere before field is used (maybe something like lazy init)
3) Can inits use this/type?
- yes, but only when using earlier initialized fields (y = x + 1  means y =
this.x + 1)
- yes, if field is marked "init after c-tor" (c-tors have very good feature:
they are thread-safe, so thread-safe field init should take place there)
- no (all examples will be invalid)
- yes (but issue a warning in that case, "this" isn't fully constructed when
inits are run)
4) Can inits be skipped?
- no
- yes, when field/c-tor is marked with special attribute (possibly it'll be
useful for Record macro)
- yes if we can check that a particular field is correctly
initialized somewhere in particular ctor

Let's discuss what will be the best choice.
As for me, I've listed options from best to worst in my opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /mailman/pipermail/devel-en/attachments/20070314/abd8ef14/attachment.html