Skip to content

Add support for types xs:dateTimeStamp and xs:error - #2550

Merged
ChristianGruen merged 4 commits into
BaseXdb:mainfrom
GuntherRademacher:types
Nov 26, 2025
Merged

ChristianGruen merged 4 commits into
BaseXdb:mainfrom
GuntherRademacher:types

Conversation

@GuntherRademacher

Copy link
Copy Markdown
Member

This PR adds implementations for the types xs:dateTimeStamp and xs:error.

The implementation of xs:error shares similarities with the earlier proposal to introduce a none type in #2160. However, unlike that proposal, xs:error is implemented as an atomic type, allowing us to reuse most of the existing infrastructure and simplifying the overall implementation.

The original motivation for #2160 was to improve tail-call optimization by disregarding the result type of fn:error, and this benefit is still achievable with the current approach (see the new test case TCOTest.typeCheckOnFnError). However, since the declared return type of fn:error has since been generalized to item()*, it is now necessary to explicitly use cast as xs:error in order to take advantage of this optimization.

@ChristianGruen

Copy link
Copy Markdown
Member

However, since the declared return type of fn:error has since been generalized to item()*, it is now necessary to explicitly use cast as xs:error in order to take advantage of this optimization.

Perhaps we should suggest changing the return type to xs:error. What do you think?

@GuntherRademacher

Copy link
Copy Markdown
Member Author

Perhaps we should suggest changing the return type to xs:error. What do you think?

In fact I was expecting that, and I think we should. This would also align with what the spec says in 3.2.10. The type xs:error:

The practical uses of xs:error as a sequence type are limited, but they do exist. For instance, an error-handling function that always raises a dynamic error never returns a value, so xs:error is a good choice for the return type of the function.

A number of QT4 test cases would fail when the signature is changed with the implementation in this PR, those would need to be adapted.

101,115d100
< K-ErrorFunc-10
< exactly-one((true(), error()))
< Error : FORG0005: Exactly one item expected.
< Expect: FOER0000
<
< K-SeqExactlyOneFunc-7
< exactly-one((true(), error()))
< Error : FORG0005: Exactly one item expected.
< Expect: FOER0000
<
< K-SeqExactlyOneFunc-8
< exactly-one(( error(), true()))
< Error : FORG0005: Exactly one item expected.
< Expect: FOER0000
<
821,825d805
< K-SeqRemoveFunc-13
< remove(error(), 1)
< Result:
< Expect: any of { FOER0000, XPST0005 }
<
1715,1719d1694
<
< K-FunctionProlog-52
< declare function local:myFunction() as empty-sequence() { fn:error() }; local:myFunction()
< Error : XPTY0004: Empty sequence expected, xs:error found: error().
< Expect: FOER0000

@ChristianGruen
ChristianGruen merged commit 169e1ad into BaseXdb:main Nov 26, 2025
1 check passed
@ChristianGruen
ChristianGruen deleted the types branch November 26, 2025 11:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants