Re: Why is creating of if Expressions not allowed?
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.
Re: Another Tuesday (Friday?), Another GtkDcoding Blog Post
Sunday Blog eXtra: Installing and Using a Linux Build Environment URL: http://gtkdcoding.com/2019/03/24/x0002-gtkd-in-a-linux-environment.html
Re: Why is creating of if Expressions not allowed?
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.
Re: Why is creating of if Expressions not allowed?
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.
Re: Why is creating of if Expressions not allowed?
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.digitalmar...@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?
Re: Why is creating of if Expressions not allowed?
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());
}
Re: Why is creating of if Expressions not allowed?
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?
Re: Why is creating of if Expressions not allowed?
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;
Why is creating of if Expressions not allowed?
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
Re: "if" statement
On 24.03.19 13:45, Francesco Mecca wrote:
```
alias Alg = Algebraic!(int, string);
void main()
{
int n = 2;
Alg value;
value = n == 2 ? 2 : "string";
}
```
The original code used SumType but the effect is the same.
I suppose that I could write the following:
```
if(n == 2) value = 2;
else value = "string";
```
Is there a workaround for this that maintains a similar syntactic
structure?
value = n == 2 ? Alg(2) : Alg("string");
is this behaviour accepted
Yes.
or should the compiler translate the first
case in the second?
No.
"if" statement
https://run.dlang.io/is/zRcj59
```
alias Alg = Algebraic!(int, string);
void main()
{
int n = 2;
Alg value;
value = n == 2 ? 2 : "string";
}
```
The original code used SumType but the effect is the same.
I suppose that I could write the following:
```
if(n == 2) value = 2;
else value = "string";
```
Is there a workaround for this that maintains a similar syntactic
structure?
is this behaviour accepted or should the compiler translate the
first case in the second?
Re: Another Tuesday (Friday?), Another GtkDcoding Blog Post
On Saturday, 23 March 2019 at 07:18:02 UTC, number wrote: The first one :), now there's still the other one "Here’s a second code file for you." Done. Thanks, eh.
