)
To not enter that discussion on the GitLab, as I don’t want to clutter it up with questions. I ask here.
Why is the operator[1](https://cmake.org/cmake/help/latest/variable/CACHE.html),[2](https://cmake.org/cmake/help/latest/variable/ENV.html#variable:ENV)-syntax used for scoped variables (i.e. CACHE{} and ENV{}), not used more broadly in CMake?
I suppose that these operators act like read only scopes. Not actually persistent metadata/type information. So perhaps using it like `VERSION_MATCHES $SCHEME{"x.y.z-pre"}` would be very different from the current behaviour. Would something like `$SCHEME:{VERSION_MATCHES}` also not work?
Having some concept of generics/templates would be the only way to solve this in a way that doesn’t make CMake harder to maintain, nor introduces new types that make implementing CMake harder/less stable?
---
### Author:  [@vito.gamberini](https://discourse.cmake.org/u/vito.gamberini)
#### Post date: [July 26, 2026, 4:10pm UTC](https://discourse.cmake.org/t/question-about-non-numeric-versioning-discussion/15761/2 "2026-07-26T16:10:46Z")
`CACHE{}` and `ENV{}` are query domains with well defined semantics, not arbitrary transforms or views of existing data. They’re not functions.
It’s unclear what `SCHEME{}` would be querying into, which you have already pointed out.
That’s the whole reason. It’s not more complicated than “such a thing does not exist within CMake, implementing it would be a deal of work, and it’s unclear that syntax is good or intuitive”.
---
### Author:  [@Wallby](https://discourse.cmake.org/u/Wallby)
#### Post date: [July 28, 2026, 9:44am UTC](https://discourse.cmake.org/t/question-about-non-numeric-versioning-discussion/15761/3 "2026-07-28T09:44:11Z")
Isn’t ENV{} actually not read only? It can be set, and applies to the current process (sort of, but does not persist in the cache/between different cmake runs).
Well SCHEME{} would here merely be a pure-function. No side effects. So not a function in the general sense of the word. No more than CACHE and ENV are.
Something like $OVERLOAD{VERSION\_MATCHES SEMVER} would be well defined. It would query into the language itself. Merely providing a syntax for making overloads more predictable (such as in VERSION\_MATCHES in `if(... VERSION_MATCHES ...)`).
Currently as there is no way to organise this kind of thing you have discussion going like the #23649 one.
---
### Author:  [@vito.gamberini](https://discourse.cmake.org/u/vito.gamberini)
#### Post date: [July 28, 2026, 6:03pm UTC](https://discourse.cmake.org/t/question-about-non-numeric-versioning-discussion/15761/4 "2026-07-28T18:03:58Z")
`ENV` isn’t read only, the point is it’s not a function call. It’s a query, a load or a store. All variable expansions are. That includes regular variables, `ENV{}`, and `CACHE{}`. The CMake internals do not model these as transformations over the underlying data.
We could, we don’t, and that’s the whole story. If you want to transform a string from one form to another you write a function to do that.