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

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.

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

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

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.

(Always writes reference.)

(Copies to expanded type, else writes reference.)

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

Print the expression viewed as a target plus the corresponding dot 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 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.

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

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

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

During this last step RUN_FEATUREs are prepared too.

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

The goal of this extra {TYPE_MARK} is to remove a possible ambiguity in case of multiple inheritance.