Skip to content

Use more precise AnyList and AnyStruct in the Value schema#2501

Merged
kentonv merged 4 commits into
capnproto:v2from
RReverser:anylist-schema
May 5, 2026
Merged

Use more precise AnyList and AnyStruct in the Value schema#2501
kentonv merged 4 commits into
capnproto:v2from
RReverser:anylist-schema

Conversation

@RReverser

Copy link
Copy Markdown
Contributor

This changes Value.list and Value.struct from AnyPointer to its narrower counterparts.

This improves type safety for external codegens, but of course requires some changes in C++ as well. In particular, I'm not 100% sure about my getValuePointer approach to getting the default value as non-dereferenced raw pointer again after this change, if there's a better way, I'm happy to change it.

As far as I can tell, this schema change is backward-compatible and no renumbering is necessary.

@codspeed-hq

codspeed-hq Bot commented Jan 12, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 15 untouched benchmarks


Comparing RReverser:anylist-schema (534840f) with v2 (6535f9b)

Open in CodSpeed

Comment thread c++/src/capnp/pointer-helpers.h
Comment thread c++/src/capnp/dynamic.c++
This changes Value.list and Value.struct from AnyPointer to its narrower counterparts.

This improves type safety for external codegens, but of course requires some changes in C++ as well. In particular, I'm not 100% sure about my  `getValuePointer` approach to getting the default value as non-dereferenced raw pointer again after this change, if there's a better way, I'm happy to change it.

As far as I can tell, this schema change is backward-compatible and no renumbering is necessary.
This prevents them being expanded in diffs by default, which makes diffs easier to read.
@RReverser

RReverser commented Apr 23, 2026

Copy link
Copy Markdown
Contributor Author

Btw another alternative to this PR could be to eliminate struct/list/interface variants from Value altogether - AnyPointer type already has its own nested information about which kind of pointer it is, so having variants at the Value level as well seems redundant, Value.anyPointer variant would be enough to represent all of them.

Or vice versa, remove Value.anyPointer and keep only the strongly-typed variants - a bit more cumbersome but also avoids redundancy.

But I guess it's too much of a breaking change either way.

@kentonv kentonv merged commit fbabfd5 into capnproto:v2 May 5, 2026
13 checks passed
pull Bot pushed a commit to kokizzu/cloudflare-workerd that referenced this pull request May 11, 2026
capnproto/capnproto#2501 introduced a source-breaking change:
schema::Value::Reader::getStruct() now returns capnp::AnyStruct::Reader
(with as<T>()) instead of capnp::AnyPointer::Reader (with getAs<T>()).

Bump capnp-cpp past it and update the two getStruct().getAs<T>() callers
in compatibility-date.{c++,-test.c++} to use as<T>().

Assisted-by: OpenCode:claude-opus-4.7
@RReverser RReverser deleted the anylist-schema branch May 20, 2026 19:49
meefs pushed a commit to meefs/workerd that referenced this pull request Jun 1, 2026
capnproto/capnproto#2501 introduced a source-breaking change:
schema::Value::Reader::getStruct() now returns capnp::AnyStruct::Reader
(with as<T>()) instead of capnp::AnyPointer::Reader (with getAs<T>()).

Bump capnp-cpp past it and update the two getStruct().getAs<T>() callers
in compatibility-date.{c++,-test.c++} to use as<T>().

Assisted-by: OpenCode:claude-opus-4.7
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