Why GLSL Prohibits Identifiers With Double Underscores
The OpenGL Shading Language (GLSL) strictly reserves any identifier
that begins with or contains consecutive underscores (__).
This article explains the technical rationale behind this rule, showing
how this reservation protects internal compiler namespaces, prevents
conflicts with built-in preprocessor macros, and ensures consistent
cross-vendor shader compilation by borrowing established conventions
from the C and C++ standards.
Reserved Implementation Namespace
Shader compilation is not handled by a single unified compiler; instead, individual GPU driver vendors (such as NVIDIA, AMD, Intel, and Qualcomm) compile GLSL source code into hardware-specific machine instructions. During this compilation pipeline, the driver often transforms, lowers, or injects internal helper variables, intrinsic functions, and vendor-specific runtime routines directly into the Abstract Syntax Tree (AST).
By strictly barring developers from using identifiers with consecutive underscores, the GLSL specification guarantees a dedicated, collision-free namespace that driver vendors can safely use for intermediate representations and internal code generation.
Protection of Preprocessor Macros
GLSL relies on a standard preprocessor derived from C. Standard system-defined macros uniformly utilize double underscores to distinguish core environment variables from user-defined macros. Examples include:
__LINE__: Evaluates to the current source line number.__FILE__: Evaluates to the current source string number.__VERSION__: Evaluates to the decimal integer of the GLSL version.
If users were allowed to define tokens containing __,
accidental overriding or shadowing of these fundamental directives could
cause erratic compiler behavior or silent failures during conditional
compilation routines.
Alignment with C and C++ Standards
GLSL was intentionally designed with a syntax familiar to C and C++ programmers. Both the ISO C standard (ISO/IEC 9899) and the ISO C++ standard (ISO/IEC 14882) explicitly state that identifiers containing double underscores anywhere within their names are reserved for the implementation. GLSL adopted this rule directly to maintain syntactic and architectural consistency with its host languages, preventing cognitive friction and code-generation discrepancies between CPU and GPU codebases.
Avoiding Accidental Mangling Conflicts
Compilers frequently use name mangling to implement language features such as function overloading, which GLSL supports natively. Double underscores are frequently used as delimiters in name-mangling schemes to separate function names from parameter type encodings. Permitting double underscores in user code could lead to demangling ambiguities or accidental symbol collisions when the compiler generates flattened symbols for the linker stage.
Portability Across Hardware Vendors
Because GPU drivers vary significantly in their implementation details, code that happens to work on one vendor's driver might crash or fail to compile on another if user identifiers clash with a specific vendor’s internal routines. Enforcing a total ban on consecutive underscores at the language level guarantees that user code remains completely isolated from internal driver implementations across all platforms.