[Nix#8613] Make sure we can fix the parser's bad list/number interactions #135
Labels
No labels
Area/build-packaging
Area/cli
Area/evaluator
Area/fetching
Area/flakes
Area/language
Area/profiles
Area/protocol
Area/releng
Area/remote-builds
Area/repl
Area/store
bug
crash 💥
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
testing/flakey
ux
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#135
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Upstream-Issue: NixOS/nix#8613
Is your feature request related to a problem? Please describe.
We have to obscure syntaxes that can be argued to be bugs; certainly one of them.
However, changing the tokenizer/parser for them technically means breaking the language.
[ 01.1 ] == [ 1 0.1 ]
[ 0xff ] == [ 0 xff ]
ifxff
is in scopeI think bug for bug compatibility is valuable, but also costly. In this case the cost/benefit of bug for bug compatibility seems off, and we may have a way out.
Describe the solution you'd like
Language versioning would be great, but going this route also means that we'd have to indefinitely support the bad syntax.
So regardless of the language versioning idea, we can run an experiment to verify that the community does not rely on the bad syntax, and then "break" the syntax to no ill effect.
Benefits:
Method:
Describe alternatives you've considered
Wait for language versioning and maintain the bad syntax forever even if there's no benefit of doing so.
Additional context
Priorities
Add 👍 to issues you find important.