Used both for specialize_in and specialize_thru to indicate that we have all FEATURE_STAMPs
ready for use and that FEATURE_NAMEs are no longer used (except for calls on non-current target
who are available after specialize_2 -- step).
Assuming that Current is already specialized in parent_type, now specialize Current for the
new_type knowing that this source code is inherited thru parent_edge.
True when the evaluation of Current has no side effect at all (i.e. no memory allocated, no
modification in the _heap_ memory, no external code with possible side effect).
The specialize_2
step has been added to continue specialization which can't be made at specialize_in / specialize_thru
time (because the expression TYPE computation may involve TYPEs who don't yet exist).
At specialize_2 step, all TYPEs used by Current expression are ready, so TYPE may be known for all
sub-members (target, arguments) using resolve_in, if we take care to call specialize_2 on them
before calling resolve_in. So we can continue the specialization process and perform some validation
checks knowing the TYPE of other components.
After this specialize_2 has been called on Current, resolve_in can be used to know the
Current expression result TYPE.
Specialize Current knowing that the corresponding source code was written in type.
The Result
still contains all the original source code information in order to be able to specialize_in again
the Result in another type. (See also specialize_thru and has_been_specialized as well.)
Used both for specialize_in and specialize_thru to indicate that we have all FEATURE_STAMPs
ready for use and that FEATURE_NAMEs are no longer used (except for calls on non-current target
who are available after specialize_2 -- step).
Finally, also note that the purpose of this
feature is mostly to write contracts (see also the strange ensure assertion).
Assuming that Current is already specialized in parent_type, now specialize Current for the
new_type knowing that this source code is inherited thru parent_edge.
True when the evaluation of Current has no side effect at all (i.e. no memory allocated, no
modification in the _heap_ memory, no external code with possible side effect).
Actually, when
side_effect_free is True, Current can be evaluated more than once or not evaluated at all.