OCL21 — Exact type of Set{} and missing Set(MyType){} literal definitions

Summary:
It is not clear what is the concrete type of Set{}. Is it Set(Object), Set(Void)
Also it seems there is no way to explicitly define an empty collection with a given
type for the elements.

Discussion of this issue suggested a number of options:
Option 1: The type of Set{} is Set(OclVoid)
This does not work because
Set{}->including(1)
is an error since "1" or indeed anything other than null or invalid does not
conform to OclVoid.
Option 2: The type of Set{} is Set(OclAny)
This does not work because
acc : Set(Integer) = Set{}->including(1)
is an error since Set(OclAny) is not compatible with Set(Integer).
Option 3: The type of Set{} is a new built-in type EmptySet(ET) where ET is
determined in some way.
This does not work because given the RHS of
acc : Set(Integer) = Set{}>including(1.0)
>including(Classifier)>excluding(1.0)>excluding(Classifier)
it is difficult to see how ET could be determined more precisely than OclAny
causing the same problem as Option 2.
Option 4: The type of Set{} is Set(null)
Since Set{} and Set(null) have no precise OCL 2.1 semantics there is some
discretion in defining them, but eventually a dynamic type validation is needed for
acc : Set(String) = Set(null)

. The impact on evaluation could be
mitigated by synthesis of an oclAsType() in the Abstract Syntax Tree, but it is not
18
possible to provide a static type for the CollectionLiteralExp. This option could
work but requires revision of abstract syntax and evaluation specifications.
Option 5: The type of Set{} is back-propagated
For instance in
acc : Set(Real) = Set{}>including(1)>including(-1)
the type of Set{} is Set(Real) since that is the eventual result type. This involves
unusual reverse semantics.
Option 6: The type of Set{} is Set(T) with T chosen for well-formedness of the
expression in which the Set{} is used.
For instance in
acc : Set(Real) = Set{}>including(1)>including(-1)
the type of Set{} is initially Set(T) where T <= OclVoid. Propagation of the type to
Set(T)::including(UnlimitedNatural) requires T <= UnlimitedNatural. Propagation
to Set(T)::including(Integer) requires T <= Integer. Finally, propagation to the
initializer requires Real <= T. Therefore any Real <= T <= Integer is well-formed.
The lower bound, Set(Real), is preferred since it avoids many type conversions.
It is also the same result as Option 5.
Option 6 involves only additional forward static semantics, has no impact on
evaluation, no impact on parsing, and gives the intuitively correct OCL 2.1
results.

In order to impose a user-specified element type and so get static type checking
of user intent, a collection element type can be specified as:
acc : Set(Integer) = Set(Integer){}
It is difficult to parse this in OCL 2.1 because Set is not a reserved word and so
lookahead is required to determine whether Set(someName) is the start of a
StringLiteralExpCS or an OperationCallExpCS, with someName perhaps being a
complicated nested type/value ambiguity.
Issue 14357 introduces the concept of a restricted word preventing the
unqualified use of Set as an operation name. The extension is then
straightforward.