CMake’s command parser and variable parsers are two completely separate things. The first is an unnecessarily complicated lax/yacc generated thing that does balanced parentheses, comment, and quote/square brackets computations to find the last parenthesis. This returns a command name and a string to split into arguments cmMakefile::ExpandVariableInString then takes the argument list and expands arguments where some other routine then picks up and splits it into actual arguments (with quoting information). This proposed syntax would need to merge these somehow which seems…unlikely. Given CMake’s wonky argument semantics, is this allowed?
function (thought_experiment)
return (somevar STREQUAL)
endfunction ()
if (though_experiment() "a string")
message("hmm")
else ()
message(
"functions can't return lists? "
"returned lists are not expanded at their use site? "
"what is the exception here? "
"is this just another `if` special case? why?")
endif ()
So I think any such real-world collision has far more problems than the name collision to consider. The syntax parser would hopefully have which is which be 100% unambiguous anyways (if is a bit special here, but any other variable naming occurs within a $key{ style expansion, so that should be unambiguous. You probably lose on ${thought_experiment()}, but even that may be an acceptable future since () are invalid characters in literal variable names today anyways:
set("thought_experiment()" value)
set(varname "thought_experiment()")
set(expanded "${varname}") # expands to "value"
But explaining the difference between the above and ${though_experiment()} is going to be tricky, so probably not the best idea.