OCL23 — OCL 2.1 Implicit Conversion to Collection Literal

The specification is very vague as to how and when a non-collection is converted to a collection.

11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

7.5.3 states that 'Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.'

The collection type inconsistency between Bag{} and Set

makes compile-time type resolution difficult, since the null-ness of x cannot be known till run-time. It would be better to have either Set or Bag uniformly as the conversion collection type. Bag{} as the least useful seems more appropriate.

When a conversion is applicable is unclear.

In the example, self.manager->isEmpty() is intended to be interpreted as

if self.manager.isUndefined() then Set{} else Set

endif->isEmpty()

so that null->isEmpty is also valid.

However is

null->excludesAll(null)

equivalent to

Bag{}->excludesAll(Bag{})

and so true?

A simple policy of 'wherever a collection is required and a non-collection is provided perform an implicit conversion to collection-literal' resolves this.

However are

null = Bag{}

or

Bag{} = null

both equivalent to

Bag{} = Bag{}

and so true?

In this case we have a problem of asymmetric overloading.

null = Bag{} satisfies the signature for OclVoid::=(OclAny) and so returns false.

Bag{} = null could satisfy the signature for Bag::=(Bag) and so return true with the help of an implicit conversion.

Presumably an additional OclVoid::=(Collection) overload is needed to restore symmetry.

Resolved by Issue 15009, where the explicit synthesis of oclAsSet() avoids the troublesome conversions above.
Disposition: See issue 15009 for disposition