Thread overview
Why is creating of if Expressions not allowed?
Mar 24
sighoya
Mar 24
sighoya
Mar 24
Alex
Mar 24
sighoya
Mar 24
sighoya
March 24
Why

auto GenIf()()
{
    return mixin("if(true) { return true;} else {return false;}");
}

public bool testFunction2()
{
    GenIf!();
}


gives me:

onlineapp.d-mixin-3(3): Error: expression expected, not if
onlineapp.d(8): Error: template instance `onlineapp.GenIf!()` error instantiating


March 24
On Sunday, 24 March 2019 at 16:18:49 UTC, sighoya wrote:
> Why
>
> auto GenIf()()
> {
>     return mixin("if(true) { return true;} else {return false;}");
> }
>
> public bool testFunction2()
> {
>     GenIf!();
> }
>
>
> gives me:
>
> onlineapp.d-mixin-3(3): Error: expression expected, not if
> onlineapp.d(8): Error: template instance `onlineapp.GenIf!()` error instantiating

Because D uses if statements, no if expressions.
The equivalent of an if expression is the ternary operator:
    bool-condition ? if-true : if-false;

March 24
On Sunday, 24 March 2019 at 16:57:25 UTC, Rémy Mouëza wrote:
> On Sunday, 24 March 2019 at 16:18:49 UTC, sighoya wrote:
>> Why
>>
>> auto GenIf()()
>> {
>>     return mixin("if(true) { return true;} else {return false;}");
>> }
>>
>> public bool testFunction2()
>> {
>>     GenIf!();
>> }
>>
>>
>> gives me:
>>
>> onlineapp.d-mixin-3(3): Error: expression expected, not if
>> onlineapp.d(8): Error: template instance `onlineapp.GenIf!()` error instantiating
>
> Because D uses if statements, no if expressions.
> The equivalent of an if expression is the ternary operator:
>     bool-condition ? if-true : if-false;

Hmm..., sounds like bad news. Is there any mixin technology for statements?

March 24
On Sunday, 24 March 2019 at 16:18:49 UTC, sighoya wrote:
> Why
>
> auto GenIf()()
> {
>     return mixin("if(true) { return true;} else {return false;}");
> }
>
> public bool testFunction2()
> {
>     GenIf!();
> }
>
>
> gives me:
>
> onlineapp.d-mixin-3(3): Error: expression expected, not if
> onlineapp.d(8): Error: template instance `onlineapp.GenIf!()` error instantiating

You can't return the result of a string mixin from a function. Instead, return a string from your `GenIf` function, and mix it in at the call site:

string GenIf()
{
    return "if (true) { return true; } else { return false; }";
}

bool testFunction()
{
    mixin(GenIf());
}
March 24
On Sunday, 24 March 2019 at 18:18:39 UTC, sighoya wrote:
>
> Hmm..., sounds like bad news. Is there any mixin technology for statements?

There was a recent thread on this.

https://forum.dlang.org/post/mailman.6499.1547823247.29801.digitalmars-d@puremagic.com

However, do you have a clear use case, where statement mixin would be considerably more profitable than the replacements suggested by Remy and Paul?
March 24
On Sunday, 24 March 2019 at 18:43:51 UTC, Paul Backus wrote:
> You can't return the result of a string mixin from a function. Instead, return a string from your `GenIf` function, and mix it in at the call site:
>
> string GenIf()
> {
>     return "if (true) { return true; } else { return false; }";
> }
>
> bool testFunction()
> {
>     mixin(GenIf());
> }

Thanks for mentioning this, this was where I looking for.
March 24
On Sunday, 24 March 2019 at 18:18:39 UTC, sighoya wrote:
> Hmm..., sounds like bad news. Is there any mixin technology for statements?

mixin() works for statements too.

It is the *context* though. If mixin() appears where the compiler expects an expression, it must give an expression. Ditto for statements (and for declarations btw). Consider

int main() {
   // compiler expecting a statement here, so
   mixin("if(true) {}"); // allowed

   // but here it is expecting an expression
   return mixin("some_expression");
}

This is also the reason why mixin sometimes requires ; and sometimes requires a LACK of ;

int main() {
   int a;
   mixin("a = 10;"); // the ; inside the mixin is required there
   return mixin("a"); // but mixin("a;"); there would be an error
}


Think of mixin() not as pasting code per se, but pasting an AST node inside the compiler's data structures. It must be a complete node of that tree that can be substituted in.
March 24
On Sunday, 24 March 2019 at 18:59:45 UTC, Adam D. Ruppe wrote:

> Think of mixin() not as pasting code per se, but pasting an AST node inside the compiler's data structures. It must be a complete node of that tree that can be substituted in.

And because AST Nodes aren't expressions means you can't pass them. This makes sense.

I would really like to use normal mixin templates for these things, but why I can't insert only declarations with mixin templates?

Sure, I can use q{} for better syntax highlighting in string mixins but I can't expand args inside them which I can however with mixin templates.