void main()
{
 int s;
 mixin("s") = 5;
}
-----
Line 4: found '=' when expecting ';'


http://www.digitalmars.com/d/1.0/expression.html#MixinExpression

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.

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.

I'm thinking about how to fix this. I think the parser should peek the next token after the closing parenthesis. If it's a semicolon, then treat it as a statement-mixin. Else, just invoke parseAssignExp and create a new ExpStatement.

I modified this in Descent and it seems to work. :-)

Here's the code (in Java, but the idea is simple to translate to C++):

// inside Parser::parseStatement
case TOKmixin: {
    Dsymbol d;
    t = peek(token);
    if (t.value == TOKlparen)
    {
        if (peekPastParen(t).value != TOKsemicolon) {
            Expression e = parseAssignExp();
            s = new ExpStatement(loc(), e);
        } else {
            // mixin(string)
            nextToken();
            check(TOKlparen);
            Expression e = parseAssignExp();
            check(TOKrparen);
            check(TOKsemicolon);
            s = newCompileStatement(loc(), e);
        }
        break;
    } else {
        d = parseMixin();
        s = newDeclarationStatement(loc(), d);
        break;
    }
}

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.

BCS wrote:
> void main()
> {
>  int s;
>  mixin("s") = 5;
> }
> -----
> Line 4: found '=' when expecting ';'
> 
> 
> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
> 
> 

mixin *expression*

(4+3) = 5;

hasen wrote:
> BCS wrote:
>> void main()
>> {
>>  int s;
>>  mixin("s") = 5;
>> }
>> -----
>> Line 4: found '=' when expecting ';'
>>
>>
>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>>
>>
> 
> mixin *expression*
> 
> (4+3) = 5;
> 

Oh, never mind,

AssignExpression can be of the form:

ConditionalExpression = AssignExpression

my bad.

Hello hasen,

> hasen wrote:
> 
>> BCS wrote:
>> 
>>> void main()
>>> {
>>> int s;
>>> mixin("s") = 5;
>>> }
>>> -----
>>> Line 4: found '=' when expecting ';'
>>> http://www.digitalmars.com/d/1.0/expression.html#MixinExpression
>>> 
>> mixin *expression*
>> 
>> (4+3) = 5;
>> 
> Oh, never mind,
> 
> AssignExpression can be of the form:
> 
> ConditionalExpression = AssignExpression
> 
> my bad.

Irony: I wrote a lib that abuses the grammer to allow exactly that kind of syntax <g>

http://www.dsource.org/projects/scrapple/browser/trunk/backmath

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.