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