Tim Schendekehl

See also [issue 21200](https://issues.dlang.org/show_bug.cgi?id=21200) and the discussion at https://digitalmars.com/d/archives/digitalmars/D/const_Class_is_mangled_as_Class_const_const_299139.html.

Unfortunately this could also affect the D compilers, because DsymbolTable.lookup and DsymbolTable.insert use "Identifier const * const". The change could make bootstrapping harder. Header generation would also need to be...

> What's the behaviour on itanium? Windows should just mangle it in the same way instead of doing something different. The outer const is already removed for itanium. See https://github.com/dlang/dmd/blob/master/src/dmd/cppmangle.d#L1464-L1465...

While implementing header generation for the changed types, I realised that this change would break more code, than I initially thought. Previously I only thought about bindings to existing C++...

DeclaratorInitializer should also get a rule with BitfieldDeclarator in the grammar. DeclaratorIdentifier is only used for declarators after the first comma, while DeclaratorInitializer is used for the first declarator.

Another potential ambiguity in the grammar: ``` void f() { a: b; } ``` The statement could be a bitfield with `a` as type and `b` as width, but it...

I can reproduce it locally. The failure happens in addVar, because `symbols` is `null` for this line: ```d defineTab[cast(void*)s.ident] = symbols.length; ```

> This is a special case that's impossible to express in the lexical grammar. It could be expressed in the lexical grammar by allowing arbitrary identifiers as a suffix and...

@ntrel I don't think it would be ambigous for integer or float literals. The lexer would accept as many identifier characters as possible, but later error on invalid characters. For...

> @tim-dlang The grammar you linked for [floating-literal](https://alx71hub.github.io/hcb/#floating-literal) seems to require either a `.` or `e`, in D you can have float literals that don't: `1F` - that would conflict...