KERML_ — Constructor invocation expressions are semantically inconsistent

8.4.4.9.4 Invocation Expressions states that:

An InvocationExpression may also have the form T(e1, e2, ...), where the invoked Type T is not a Function. In this case, the InvocationExpression acts as a constructor for an instance of the Type T.

The semantics are then that such a constructor expression is both typed by T and a subset of Performances::evaluations. Now, it is allowable for T to be a data type or a structure, that is, for it to directly or indirectly specialize Base::DataValue or Objects::Object). But this is a semantic inconsistency, because Performance (a generalization of evaluations) is disjoint with both DataValue and Object.

Add ConstructorExpression

This resolution adds ConstructorExpression to replace the use of InvocationExpressions with constructor semantics. InvocationExpressions is then limited to invoking only Functions or Behaviors. It also adds InstantiationExpression as the abstract superclass of ConstructorExpression and InvocationExpression.

In order to allow more consistent parsing, the instantiatedType of a ConstructorExpression or an InvocationExpression (other than an OperatorExpression) is parsed as a member of the expression. An InvocationExpression is then required to specialize the instantiated type, as before. In a ConstructorExpression, however, it is the result that specializes the instantiatedType. Further, unlike an InvocationExpression, whose arguments are parsed as feature values of ownedFeatures of the expression itself, the arguments of a ConstructorExpression are parsed as feature values of ownedFeatures of the result of the ConstructorExpression. In this way, a value of the instantiatedType is "constructed" as the result of the ConstructorExpression, while the expression itself can still be typed as an Evaluation.

The concrete syntax for a constructor expression is similar to that of an invocation expression, but preceded by the keyword new. Special dispensation is provided to allow non-Function Behaviors to still be essentially "constructed" using an InvocationExpression, as before. That is, if the instantiatedType of an InvocationExpression is a Behavior that is not a Function, then the InvocationExpression is still typed by the Behavior, with its result bound to itself. This does not cause semantic problems, because it is acceptable to specialize a Performance of the Behavior to an Evaluation that returns itself (see the proposed language description text for examples of this usage).