naming.hpp File Reference

The single policy for what makes a legal identifier (variable/symbol name). More...

#include <string>
#include <stdexcept>
#include <boost/regex/pending/unicode_iterator.hpp>
#include <boost/spirit/home/support/char_encoding/unicode.hpp>

Include dependency graph for naming.hpp:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Namespaces
namespace	bertini
namespace	bertini::detail

Functions
bool	bertini::detail::IsEmojiBase (char32_t cp)
	True if cp is in a primary emoji / pictographic range, so a name may start with it (🎉, 👍, ❤, ⭐, a regional-indicator letter, ...).
bool	bertini::detail::IsEmojiGlue (char32_t cp)
	True if cp only extends an emoji cluster – valid mid-name to glue a multi-code-point emoji, but not meaningful as a name's first character.
bool	bertini::IsIdentStart (char32_t cp)
	True if code point cp may START an identifier: any Unicode letter (ASCII A-Z a-z, plus Ω, α, CJK, ...) or an emoji base code point.
bool	bertini::IsIdentCont (char32_t cp)
	True if code point cp may CONTINUE an identifier: any Unicode alphanumeric, one of the legacy continuation characters [ ] _, or an emoji base / sequence-glue code point (so a whole emoji reads as one name).
bool	bertini::IsValidVariableName (std::string const &s)
	True if s is a well-formed identifier: nonempty, a valid UTF-8 IsIdentStart code point followed by zero or more IsIdentCont code points.
void	bertini::ThrowIfInvalidVariableName (std::string const &s)
	Throw std::runtime_error if s is not a valid variable name (.

Detailed Description

The single policy for what makes a legal identifier (variable/symbol name).

A name is UTF-8: it starts with a Unicode letter (ASCII A-Z a-z, or Ω, α, CJK, ...) and continues with Unicode alphanumerics or [ ] _. Classification decodes code points to UTF-32 (boost::u8_to_u32_iterator) and tests Unicode character properties – never wchar_t / the platform locale (the cp1252/latin-1 footgun).

These predicates are shared by the classic Qi grammar (see io/parsing/unicode_ident.hpp) and the object model (node::Variable), so the parser and direct construction agree on exactly what a name may be.

Emoji are allowed too (yes, really). A "multipoint" emoji – skin-toned (👍🏽), ZWJ-joined (👩‍👩‍👧), a flag (🇺🇸), or variation-selected (❤️) – is a sequence of code points, not one character, in every encoding; UTF-16/UTF-32 would not collapse it (we already decode to code points). Rather than run full Unicode grapheme segmentation (UAX #29, which needs break-property tables / ICU), we take the pragmatic route: an emoji base code point may START a name, and the sequence "glue" code points (ZWJ, variation selectors, skin-tone modifiers, regional indicators, enclosing keycap) may CONTINUE one, so a whole emoji sequence reads as a single contiguous identifier. This is not strict UAX #29, but it is more than good enough for variable names. (Name identity is still by exact code-point sequence; NFC normalization of names is a separate, deeper concern.)