QT4 CG Meeting 178 Minutes 2026-09-01

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [:07-]
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [X] Wendell Piez (WP)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 8 September.

AP gives regrets for 8 and 15 September.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [X] QT4CG-167-05: MK to write a proposal to change #2393 so the functions return JNodes
  • Competed by PR #2814
• [ ] QT4CG-167-07: NW to review tests for interpolated strings with edge cases in mind
• [ ] QT4CG-167-09: NW to close all “nice to have” issues at the end of October if they haven’t progressed
• [ ] QT4CG-170-01: RD to draft a proposal that attempts to address the lexical issues differently.
• [X] QT4CG-174-01: MK to make an issue or otherwise address CG’s comments on #2734.
  • Raised in issue #2819, resoved by PR #2856
• [ ] QT4CG-176-01: NW to see about improving the linking for record types.
• [X] QT4CG-176-02: MK to refine the strip-space option so that it takes account of historical defaults.
  • Created issue #2883
• [ ] QT4CG-177-01: NW to put the progress graphs back in the agendas.

This section summarizes all of the issues and pull requests that need to be resolved before we can finish. See Technical Agenda below for the focus of this meeting.

See PR #2768

CG summarizes the PR.

• CG: We’ve looked at this already. It fixes a couple of minor issues, and it drops the constructor functions.
  • … The type definitions are changed.
  • … Constructor functions are excluded for predefined named types.
  • … You can still get one by coercing a map to a record.
• RD: Would cast as work as well?
• MK: I think it will once another proposal has been accepted. But casting to records is not currently status quo, but it’s coming.
• JLO: Constructor functions are optional, are there any that still exist?
• CG: All built-in records don’t have constructor functions, but user-defined records will.
  • … There are other PRs that make other suggesions.
  • … Many people will never know that the built in record types exist.
• JLO: I can just pass in the map and it’ll be coerced?
• CG: Yes.

Proposal: accept this PR.

Accepted.

See PR #2789

MK introduces the PR.

• MK: This is all in XQuery; there’s an associated set of XSLT changes that follow this very closely. They’ll follow if the idea is acceptable.
  • … Background: you can currently declare a record type using declare record or declare type.
  • … There are some differences, recursive definitions and constructor functions, for example.
  • … At the very least, we should make the two thing synonyms.
  • … But what I’m proposing is to drop declare record and putting all the functionality in declare type.
• MK: There are some changes to constants that get mixed in. The default value for a record had to be a constant, but it’s now fairly irrelevant to this proposal.
  • … A couple of meta symbols are defined explicilty and an empty sequence can be explicit.
• MK: A FieldDecl within a record type always allows an initializer.
• MK: Default values for fields are described. (Section 3.2.8.3.1)
  • … Default values are particularly useful when you’re defining a record that contain methods.
  • … A ConstantExpr is just an ExprSingle with some special semantic constraints.
• MK: Recursive record types are now down with declare type rather than declare record.
  • The examples are changed.
• MK: The coercion rules for coercing a map to a record include a special rule for default values that are inline function expressions.
  • … You must use the default in the case of a method; the map you’re converting can’t override that method.
• MK: The item type declaration acquires the with constructor to construct the item type.
  • … The default is that you don’t get one.
• MK: The section on item type declarations gets some new text about records.
  • … You can have constructor functions for generalized atomic types, for example unions.
• MK: There’s a new section on using methods in records.
  • … Largely existing text moved to a new place, but you have declare type as record.
• MK: The section on amed record types disappears.
• JWL: If I had a record type which had a field that was a function but it wasn’t to be treated as a method, and I have a default value for that, does that imply I can’t overwrite it?
• MK: You can still do a map put to change it.
• JWL: But not in the constructor.
• MK: Not if you’ve defined it as an inline function.
• JWL: It concerns me that there doesn’t seem to be any way to say there’s a field that is a function but isn’t method.
• MK: The workaround is to define it by hand in a user-defined function. It biases the syntax towards functions are treated as methods.
• JWL: I’ll have to think about it some more.
• JLO: There’s a lot of good things in there. The ConstantExpr can no longer reference user defined functions?
• MK: It might be over-severe as a rection. I was trying to find something similar to static expressions in XSLT. I’ve tried to define constraints so that the default value can always be computed at compile time.
  • … The default value will always be the same and you know what it is at compile time.
• JLO: I don’t see how I can create my own record type when I can’t use my own user defined functions to initialize them.
  • … That’s too limiting.
• MK: The aim is to keep defaults simple. The other question is aligning it with the rules for default values for function parameters.
  • … We have a slightly different set of constraints there.
• MK: The big problem is, what should be the evaluation context for these default values? The declaration can appear in an as clause and one approach would have been to say you can only have an initializer if it’s appearing in a named declaration on the top level
  • … Then you could constrain it like we do for defaults for user-defined functions.
  • … The difference with record declarations is that they aren’t necessarily global; that opens questions about what happens if they refere to variables, etc.
  • … This is trying to make it draconian first to avoid edge cases.
• MK: The other avenue I considered was only allowing an initializer if it was a named record type declaration.
• JLO: The rules now state that a coercing from a map that has a function that’s the same as a method will just be replaced by the method. Is there no error?
• MK: We could possibly have an error if you try to override the value of a method.
• JLO: I think that would make sense.
• RD: On the boolean constants, the way that they’re specified, they don’t have the function namespace qualifier.
• MK: That’s not actually new. It’s not changed by this proposal.
• CG: We introduced this for annotations.

Some discussion of the contexts in which you can use true() and false().

• MK: It’s the literal sequence of characters, rather than a pseudo-function call.
• RD: Does that cause ambiguities?
• MK: No, because they don’t appear where you expect an expression.
• RD: It would be nice if you could specify them with fn:true() or the EQName.
• MK: The reason for that is that constants are used in some places where there isn’t a namespace context.
• CG: Personally, I’d be glad to preserve the declare record declaration. It’s already widely used and seems to work well. I think records are fundamental enough in 4.0 that justify having their own declarations.
• MK: Would you be happy if it was just a synonym?
• CG: It would be nice if they had all the same rules as function declarations. But if that’s too much, an alias could be sufficient. When I think of function coercions with the as keyword, I probably wouldn’t think of defining functions inside that construct. I’d use named records.
  • … I think record declarations are similar to function declarations.
  • … But maybe I’m missing the XPath perspective.
• MK: Declaring them in XPath is another problem.
• CG: Declaring record types with out the restrictions would be nice.
• RD: If declare record always created a constructor function and declare item didn’t.
• MK: There were other differences.
• RD: But that would make it easy to resolve declare record types as functions.
• JWL: I’m still bothered by the distinction between functions and methods.
  • … If you did a function valued thing that didn’t have the record type as the type of its first argument, it wouldn’t be a method.
  • … If we could use that test to decide if it should be overwritten or not, that might fix the problem.

Some discussion of a special syntax for declaring records.

• CG: In that case, you’d probably need to specify the first parameter being as that type.

MK to consider and revise.

See PR #2795

CG introduces the PR.

• CG: This was originally MK’s idea. It is a mostly mechanical change to make the gnode() to node() etc.
  • … I spent a long time, but I can’t promise I caught every change.
  • … What I didn’t change are GNode with capitals, but we don’t have the syntax gnode() as types.
• CG: I tried to avoid doing controversial edits. If we do this, we may need to consider other changes.
• MK: I’ve two slight anxieties, not really objections.
  • … Do we have it right in terms of all the global changes?
  • … The other anxiety is the effect on existing code.
  • … If users have declared a parameter as type node() and their code makes assumptions that it’s an XNode but gets called with something that isn’t an XNode, are we creating a maintenance night mare.
  • … It’s backwards compatible if they don’t use any new features.
• CG: One advantage is that self::node() would have the right meaning.
  • … But there could be unexpected consequences.
• RD: I share the same concern as MK. There are cases for things like the functx library that assume that instance of node() matches XML nodes.
  • … Things like that are likely to break.
• CG: They will break if you invoke them with JNodes.
• AP: There’s a lot of cognative dissonance at the start. We talk about whether a node is a GNode and a node() is an XNode.
• JLO: This seems to be radical, and there might be problems, but I’m in favor.
• CG: I was hesitant at first, but the more I think about it, the better it seems.
  • … So far, no one has used maps and arrays in paths. Whenever you use it, code may break.
• MK: I’m inclined to take the risk.
• RD: It would be worth auditing things like the functx library to see if there are any breakages.
• CG: I can have a look.

ACTION QT4CG-178-01: CG to review the functx library for uses of node()

• WP: We should ask, but I think the community is going to lean towards this.

Proposal: accept this PR (reservations notwithstanding).

Accepted.

See PR #2796

• CG: We’ve introduced a trusted keyword, but it’s confusing.
• CG: On the one hand we say who is running code, but is the code trusted?
  • … The other thing is, what content are you allowed to retrieve?
• CG: Maybe having two words would be good. I suggest trusted and trust-external.
• CG: The results are mostly search-and-replace.

CG reviews the changes in the XQuery specification.

• CG: In summary, it’s the same as before, but there are now different names.
• MK: I think this is okay.
• JLO: I think this is good.
• WP: I also like it.

Proposal: accept this PR

Accepted.