Raito Bezarius
1e40171ea4
This introduces a new (demanded?) feature for coercing integers in interpolation arguments under the experimental feature `coerce-integers`. This feature is being introduced behind an *experimental feature flag* due to the cautious approach we're taking. The codebase has a track record of revealing unexpected behaviors, often in subtle ways, so we want to give this sufficient time and exposure before making it stable. To remove the experimental flag, we want to see **at least two releases or six months of real-world usage -- whichever is longer** -- that demonstrate strong confidence the feature doesn't introduce regressions or unintended side effects. If that level of confidence is reached, we'll proceed to stabilize it. Change-Id: I825904719eeba8f0e2a93cd6b93cfe6cebd7d827 Signed-off-by: Raito Bezarius <raito@lix.systems>
2.5 KiB
synopsis, issues, cls, category, credits
| synopsis | issues | cls | category | credits | |||||
|---|---|---|---|---|---|---|---|---|---|
| Experimental integer coercion in interpolated strings |
|
Features |
|
Ever tried interpolating a port number in Lix and ended up with something like this?
"http://${config.network.host}:${builtins.toString config.network.port}/"
You're not alone. Thousands of Lix users suffer every day from excessive builtins.toString syndrome. It’s 2025, and we still have to cast integers to use them in strings.
To address this, Lix introduces the coerce-integers experimental feature. When enabled, interpolated integers within "${...}" are automatically coerced to strings. This allows writing:
"http://${config.network.host}:${config.network.port}/"
without additional conversion.
To enable the feature, you need to add coerce-integers to your set of experimental features.
Stabilization criteria
The coerce-integers feature is experimental and limited strictly to string interpolation ("${...}"). Before stabilization, the following must hold:
-
Interpolation-only Coercion must not occur outside interpolation. Expressions like
"" + 42must continue to fail. -
Expectation that no explicit cast are being observed Cases observing explicit coercion (e.g., via
tryEvalgadget or similar) are expected not to be load-bearing in actual production code.
Timeline for stabilization
If the feature proves safe and is widely adopted across typical usage (e.g., actual configurations in the wild turning on the flag, non-trivial out-of-tree projects using it), the experimental flag will be removed after six months of active use or two Lix releases, whichever is longer.
This avoids locking the feature in experimental status indefinitely, as happened with Flakes, while allowing time for validation and ecosystem integration.
What about coercing floats or more?
Coercion beyond integers -- such as for floats or other types -- is not planned, even under an experimental flag. Questions like "what is the canonical string representation of a float?" involve subtle and context-dependent trade-offs. Without a robust and principled mechanism to define and audit such behavior, introducing broader coercion risks setting unintended and hard-to-reverse precedents. The scope of coerce-integers is intentionally narrow and will remain so.
In terms of outlook, a proposal like https://git.lix.systems/lix-project/lix/issues/835 could pave the way for a better solution.