From a64de1bfb2f0ee65c07fc614a36796c56274689d Mon Sep 17 00:00:00 2001 From: Valentin Gagarin Date: Thu, 22 Jun 2023 14:09:52 +0200 Subject: [PATCH] remove reference to `builtins.langVersion` this is unrelated to the proposal, as the version declaration is only relevant for parsing, and would cover all use cases of `langVersion` if we have minor version numbers --- rfcs/0137-nix-language-version.md | 26 -------------------------- 1 file changed, 26 deletions(-) diff --git a/rfcs/0137-nix-language-version.md b/rfcs/0137-nix-language-version.md index e9439c6..50721c6 100644 --- a/rfcs/0137-nix-language-version.md +++ b/rfcs/0137-nix-language-version.md @@ -281,32 +281,6 @@ Other discussions around language changes: -1. `builtins.langVersion` returns the language version used for evaluating the given expression. - -
Arguments - - - (+) Could make use of it for generating Nix expressions programmatically and annotating them with the correct version - - (+) `builtins.langVersion` is already part of the stable interface, this way we can make it pure - - (-) Requires maintaining more API surface without a clear use case - -
- -
Alternatives - - - Return the latest language version instead - - - (-) Doesn't help to determine what is used for evaluating the current expression - - (+) Might provide opportunities for forward-compatible Nix code - - (-) Brittle and defeats the purpose of this RFC - - (-) Impure, the value depends on the environment - - - Don't expose `builtins.langVersion` at all - - - (+) No need to have this if the Nix files are versioned - - (+) `builtins.langVersion` is not documented and not widely used - -
- 1. Each time the language specification (currently as embodied by the Nix language evaluator) is changed, the language version must be incremented.
Arguments