Lexers (again)
Timon Gehr
timon.gehr at gmx.ch
Sun Dec 15 09:55:57 PST 2013
On 12/15/2013 05:38 PM, Andrei Alexandrescu wrote:
>>>
>>> One limitation I've noticed with the new tok!"tokenName" approach is
>>> that while dmd has no problem with
>>>
>>> case tok!"class":
>>>
>>> it does have a problem with
>>>
>>> goto case tok!"class":
>>>
>>> I managed to work around this by adding new labels and "goto"-ing them
>>> instead. Is this a bug or intentional?
>>
>> I cannot reproduce your problem. If this does not work, it is a bug.
>
> The problem is that tok is a dynamic value. It should be a static value.
Note that the spec has this to say:
http://dlang.org/statement.html#SwitchStatement
"Expression is evaluated. The result type T must be of integral type or
char[], wchar[] or dchar[]. The result is compared against each of the
case expressions. If there is a match, the corresponding case statement
is transferred to.
The case expressions must all evaluate to a constant value or array, or
a runtime initialized const or immutable variable of integral type. They
must be implicitly convertible to the type of the switch Expression.
Case expressions must all evaluate to distinct values. Const or
immutable variables must all have different names. If they share a
value, the first case statement with that value gets control. There must
be exactly one default statement."
Arguably, this is a questionable language design decision that should
IMO be revisited anyway, but DMD clearly does not follow the spec here.
Also, there is this:
"The fourth form, goto case Expression;, transfers to the CaseStatement
of the innermost enclosing SwitchStatement with a matching Expression."
It does not say anything about what kind of expression is required.
More information about the Digitalmars-d
mailing list