New Issue: Should we change the names of compilerError/Warning/Assert ?

18025, "mppf", "Should we change the names of compilerError/Warning/Assert ?", "2021-07-01T21:03:52Z"

This issue is a discussion of whether we should change the names of compilerError, compilerWarning, and compilerAssert while working towards module stability.

Note that some previous conversation about the names of these occurs in should compilerError be included by default? · Issue #16807 · chapel-lang/chapel · GitHub .

Currently we have compilerError, compilerWarning, and compilerAssert. These names have some downsides:

  • seem wordy / long
  • they are asymmetric with the execution-time commands (both because of halt vs error and because it's just halt and not executionTimeHalt e.g. )
  • "compiler" as a modifier seems strange and might be innacurate with the Chapel interpreter
  • the current method names are not verbs even though they take some action

On the other hand, these names are fairly clear and people rapidly figure out what these functions do when reading Chapel code.

Brainstorming different names, we've come up with:

  • alternatives
    • compilationError
  • ways to shorten them:
    • compError chplError paramError
  • ways to make them more verby
    • haltCompilation, haltCompiler, emitCompilationError, failCompilation, reportCompilationError`
      • but note, the corresponding warnCompilation / warnCompiler don't seem quite right
  • having e.g. halt with a `compileTime=true/false argument to help with generic programming (but we probably would still want the different function names)

Adding a compileTime=true/false argument to halt / assert / warning doesn't impact module stability so isn't a primary concern (unless the thought of adding it causes us to want to choose particular names).