[nem-en] Field initializers specification

[Kamil Skalski]

>
> 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)

Currently it is option b) and I guess there is no way (and purpose) to
"force" some kind of "first visually appeared here" rules for
macro-generated fields. Generated fields will be added to class (and
have their initializers run) after explicitly declared ones, but/and
it is totally controlled by when macro is run and what exactly it
does.

Also, the option c) is not currently supported, but it would be a good
feature (http://nemerle.org/bugs/view.php?id=696)


> 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)

Currently it is after the base c-tor... which isn't really a good thing

> 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)

There are no rules for this at the moment. I guess it would be useful
e.g. to call instance methods to initialize fields, but generally I
think that instance fields should not depend on each other - it is
much better to handle it directly in ctrs.
But for static fields, I think that the point 1c is ok - so we should
actually compute some "good" order if possible.

> 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

I agree, they should never be skipped.

These things are quite tricky, especially when we have macros, which
can arbitrarily add fields... but I think we should always head to
some agreed traget with regard to this.

-- 
Kamil Skalski
http://nazgul.omega.pl