Legal names of Vars, Funcs, etc should be well-defined/limited

[steven-johnson]

Currently, there are ~no limitations on legal identifiers for most Halide entities; setting some limits on them would make decisions about printing IR easier, and make future options for serializing IR more tractable.

Strawman proposal:

• Names must match the regex [A-Za-z][A-Za-z_0-9$]*
• Note that this is basically a C identifier, except:
  • that the first char cannot be _, so we can reserve these for future use
  • subsequent chars can include $, since that's already in semi-common use
  • Additionally, two underscores in a row are forbidden anywhere (since GLSL reserves them)

This would (probably) allow the vast majority of existing use cases with only minimal upgrade pain.

(We may also want to forbid $ in user-defined names, and reserve that for our internal use in uniquification.)

[abadams]

+1, except that the implicit vars _0, 1, etc already start with an underscore, so I don't think we can limit that. The DWARF-sniffing code will also name things according to their C-identifier, which may start with .

We could really use internal legal names that would not be legal as user-provided names, so that we can more conveniently namespace our internal stuff (e.g. the names returned by unique_name(char)). If we're maximally restrictive with user-provided names, then we always have the option of loosening up internal names later, so perhaps that doesn't need to be decided here.

[steven-johnson]

Strawman #2:

• User-provided names must match the regex [A-Za-z_][A-Za-z_0-9]*
• Additionally, two underscores in a row are forbidden anywhere (since GLSL reserves them)
• Halide-generated internal names may also use the $ character anywhere except as the first char
• All other chars are reserved for future use, forbidden for now

The gotcha here is that if we add a serializable IR in the future, the distinction between "internal" and "user-provided" becomes fuzzy-to-meaningless; we wouldn't want to have generated IR (which might contain $) illegal to parse back in.

[abadams]

You're right that user-provided names is not an adequately clean distinction in a world where people can say:

Func f1("f"), f2("f");
Func h(f2.name()); // has $ in it

Maybe in terms of invariants we just want a rule for valid identifiers in the IR, and we'll sanitize user-provided Func/Var/etc names in unique_name to map them into the space of unique valid identifiers however we like.