Actually, when side_effect_free is True, Current can be evaluated more than once or not evaluated at all.

When it is needed, C code to check invariant is automatically added as well as a C cast according to the destination target_formal_type.

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.

Also note that some default values like NULL_POINTER, cannot be written in pure Eiffel. (Thanks to the new ?:= operator, this is_default_value frozen definition is pretty fine.)

It is important to keep in mind that the resolve_in function must not be called from some specialize_in / specialize_thru function (those functions are used when *one* TYPE is created and current expression may refer to TYPEs not yet created) Hence, resolve_in calls are likely to occurs during the specialize_2 process or later if it is necessary, but specialize_2 *must* have been called on Current expression before resolve_in is called. One may also know that resolve_in function may be called one or more times or may not be called at all. (Note that the require assertion is checking that we are not currently doing some specialize_in / specialize_thru.)

As inheritance and redefinitions are ignored, it's the type to use for a lookup (for a method with this expression as target).

Note: this is the written one i.e. not always a static one.

The Result indicates the TYPE of Current expression in type. The same call may occurs more than once during the compilation process until for example the magic_count to be stabilized. Also note that the Result must be the one given by a similar resolve_in call.

During this last step RUN_FEATUREs are prepared too.

For example, this is True for True, False, Void, 2, "foo", 2.5, etc.

(Always writes reference.)

(Copies to expanded type, else writes reference.)

As an example, this is True for infix calls. (This feature is used for pretty as well as for short). As another example, it is also true (-1).foo because of the usual low priority of prefix minus.

Print the expression viewed as a target plus the corresponding dot when it is necessary.

Add a bracket pair around Current only when it is necessary.

Same as short, but here, the Current expression is itself the target of some call, hence this call may add a dot (".") only when it is needed.

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

Finally, also note that the purpose of this feature is mostly to write contracts (see also the strange ensure assertion).

(See also specialize_in and has_been_specialized as well.)

Useful for generated code

For an EXPRESSION the C code to access the value (user's expanded are no longuer pointer).