[Bug 29586] [XP31] 2.5.6.2 The judgement subtype-itemtype(Ai, Bi)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29586

--- Comment #21 from Tim Mills <tim@cbcl.co.uk> ---
(ACTION A-646-05)

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>

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 20 June 2016 11:06:12 UTC