is this right??

[Ary Borenszweig]

BCS escribió:
> Hello Ary,
> 
>> BCS escribió:
>>
>>> Hello BCS,
>>>
>>>> void main()
>>>> {
>>>> int s;
>>>> mixin("s") = 5;
>>>> }
>>>> -----
>>>> Line 4: found '=' when expecting ';'
>>>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>>> (mixin("s")) = 5;
>>>
>>> Given that the above works, it looks like the parser prematurely
>>> commits to a mixin declaration when it finds "mixin (" at function
>>> scope.
>>>
>>> Unless someone spots a flaw in this, I'll post a bug.
>>>
>> Yes, at that point the parser is parsing statements, so if it finds a
>> "mixin(...)" it turns it into a statement.
>>
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=3073
> 
> Hope you don't mind me quoting you.

Not at all!

But later when I went to sleep I thought about that a little more, and 
look at this:

1. mixin("int x = 2;");
2. mixin("x = 2");

The first should be treated as a MixinStatement, because it ends with a 
semicolon. The second should be treated as a MixinExpression, because it 
doesn't end with a semicolon (and it's a perfectly valid expression, 
it's an assign expression). But according to my patch it'll be treated 
as a statement and it'll fail.

Now this:

3. mixin("int x = 2");

is neither of them.

You can only deduce that information if you can extract the contents of 
the mixin, paste it in the source file and treat the whole line as a 
statement, and you'd get things right. But now all of those lines can be:

mixin(secret());

and now you don't know, you'll have to wait for semantic anlaysis to 
know that, but then it's too late.

But I think my patch is reasonable because it allows you to do more 
things than before, it's backwards compatible and also you'd almost 
never do number 2 but instead use number 1.