ACTION A-646-05

ACTION A-646-05: Tim to clarify the changes he's proposing for bug 29586
(subtype-itemtype).

3.1.5.1 Evaluating Static and Dynamic Function Calls

signature: The signature of F, removing the parameter type at each of 
the fixed positions. <INS>An implementation which can determine a more 
specific signature (for example, through use of type analysis) is 
permitted to do so.</INS>


3.1.7 Inline Function Expressions

signature: A FunctionTest constructed from the Annotations and 
SequenceTypes in the InlineFunctionExpr.  <INS>An implementation which 
can determine a more specific signature (for example, through use of 
type analysis of the function's body) is permitted to do so.</INS>


2.5.6.2 The judgement subtype-itemtype(Ai, Bi)

<INS>
* Ai is map(K, V), and Bi is function(xs:anyAtomicType) as V?.
* Ai is array(X) and Bi is function(xs:integer) as X.
</INS>

2.5.5.8 Map Test

<DEL>
The function signature of the map, treated as a function, is always 
function(xs:anyAtomicType) as item()*, regardless of the actual types of 
the keys and values in the map. This means that a function item type 
with a more specific return type, such as function(xs:anyAtomicType) as 
xs:integer, does not match a map in the sense required to satisfy the 
instance of operator. However, the rules for function coercion mean that 
any map can be supplied as a value in a context where such a type is the 
required type, and a type error will only occur if an actual call on the 
map (treated as a function) returns a value that is not an instance of 
the required return type.
</DEL>

<INS>
The function signature of a map matching type map(K, V), treated as a 
function, is function(xs:anyAtomicType) as V?.  It is thus always a 
subtype of function(xs:anyAtomicType) as item()* regardless of the 
actual types of the keys and values in the map.  The rules for function 
coercion mean that any map can be supplied as a value in a context where 
the required type has a more specific return type, such as 
function(xs:anyAtomicType) as xs:integer, even when the map does not 
match in the sense required to satisfy the instance of operator. In such 
cases, a type error will only occur if an actual call on the map 
(treated as a function) returns a value that is not an instance of the 
required return type.
</INS>

2.5.5.9 Array Test

<DEL>
The function signature of the array, treated as a function, is always 
function(xs:integer) as item()*, regardless of the actual member types 
in the array. This means that a function item type with a more specific 
return type, such as function(xs:integer) as xs:integer, does not match 
an array in the sense required to satisfy the instance of operator. 
However, the rules for function coercion mean that any array can be 
supplied as a value in a context where such a type is the required type, 
and a type error will only occur if an actual call on the array (treated 
as a function) returns a value that is not an instance of the required 
return type.
</DEL>

<INS>
The function signature of an array matching array(X), treated as a 
function, is function(xs:integer) as X.  It is thus always a subtype of 
function(xs:integer) as item()* regardless of the actual member types in 
the array.  The rules for function coercion mean that any array can be 
supplied as a value in a context where the required type has a more 
specific return type, such as function(xs:integer) as xs:integer, evnm 
when the array does not match in the sense required to satisfy the 
instance of operator. In such cases, a type error will only occur if an 
actual call on the array (treated as a function) returns a value that is 
not an instance of the required return type.
</INS>

Received on Monday, 20 June 2016 11:07:50 UTC