Skip to content

Conversation

@czechboy0
Copy link
Contributor

Motivation

Fixes #78.

Since ConfigSnapshotReader is being sent through async sequences, we can't take advantage of any non-copyable/non-escapable optimizations on it, which brings the ConfigReader.withSnapshot method into question - why is it a with-style method, when simply returning a snapshot reader would work just fine? ConfigProvider.snapshot() already has this spelling.

This benefits consistency, because there isn't any reason the ConfigSnapshotReader needs to be scoped, this API shape came from an earlier experiment where we thought we could use a non-copyable/non-escapable type. But right now it's not providing any benefits and is just providing a slightly less ergonomic API for users.

Modifications

Renamed ConfigReader.withSnapshot(_:) to ConfigReader.snapshot().

Result

More consistent, simpler API.

Test Plan

All tests pass.

@czechboy0 czechboy0 requested a review from FranzBusch November 24, 2025 08:37
@czechboy0 czechboy0 added the 🆕 semver/minor Adds new public API. label Nov 24, 2025
@czechboy0 czechboy0 enabled auto-merge (squash) November 24, 2025 09:53
@czechboy0 czechboy0 merged commit 23c6b9b into apple:main Nov 24, 2025
27 checks passed
@czechboy0 czechboy0 deleted the hd-simplify-snapshot branch November 24, 2025 10:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🆕 semver/minor Adds new public API.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Should withSnapshot be just snapshot() -> ConfigSnapshotReader?

2 participants