Skip to content

Conversation

@czechboy0
Copy link
Contributor

@czechboy0 czechboy0 commented Nov 11, 2025

Motivation

Implementation PR for a change that will be reviewed in a proposal

Fixes #70

There was a flaw in the design of custom key decoders: if one library changed the key decoder on a ConfigReader, and then passed the ConfigReader to another library, that second library would break, because it was expecting the default dot-based key decoder. This means that at least, ConfigReader is the wrong place for the custom keyDecoder property, and possibly there isn't a good place for it at all.

Modifications

This PR removes the whole concept of custom keyDecoders and hardcodes everything to use the dot-based one. This also unlocks making ConfigKey ExpressibleByStringLiteral, which in turn allows us to remove half of all the method overloads on ConfigReader and friends.

Result

No custom keyDecoder feature. If we find a better to way in the future, we can always introduce it back in an API-stable way. But right now it wasn't pulling its weight.

Test Plan

Adapted tests.

@czechboy0 czechboy0 added the 🆕 semver/minor Adds new public API. label Nov 11, 2025
@czechboy0
Copy link
Contributor Author

Justification - it was a very niche feature, plus: Screenshot 2025-11-11 at 4 27 22 PM

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.

Consider removing custom keyDecoders

1 participant