One thing that I miss sometimes when doing meta programming is being able to hide that a function should be called with mixin.

For example (pardon my lack of creativity):

    // Instead of
    string declare_a() {
        return "int a;"
    }

    int func() {
        mixin(declare_a);
        return a;
    }

    // Could we have?
    mixin declare_a() {
        return "int a;";
    }

    int func() {
        declare_a;
        return a;
    }

I think this could be useful when one is creating Idiom and Patterns, you could hide implementations details.

On Friday, 13 January 2017 at 21:15:32 UTC, André Puel wrote:
> I think this could be useful when one is creating Idiom and Patterns, you could hide implementations details.

I'm not sure that this is the kind of implementation detail that ought to be hidden

André Puel via Digitalmars-d <digitalmars-d@puremagic.com> napsal Pá, led 13, 2017 v 10∶15 :
> One thing that I miss sometimes when doing meta programming is being able to hide that a function should be called with mixin.
> 
> For example (pardon my lack of creativity):
> 
>     // Instead of
>     string declare_a() {
>         return "int a;"
>     }
> 
>     int func() {
>         mixin(declare_a);
>         return a;
>     }
> 
>     // Could we have?
>     mixin declare_a() {
>         return "int a;";
>     }
> 
>     int func() {
>         declare_a;
>         return a;
>     }
> 
> I think this could be useful when one is creating Idiom and Patterns, you could hide implementations details.

You can do this:

mixin template declare_a()
{
    int a;
}

int func()
{
    mixin declare_a;
    return a;
}

but there is no way to exclude mixin before calling declare_a, there is a good reason for that (it is really important to be able to tell when you use mixin and when not)

On Friday, 13 January 2017 at 21:15:32 UTC, André Puel wrote:
> I think this could be useful when one is creating Idiom and Patterns, you could hide implementations details.

it hides the fact that mixin is used, which may be undesirable. otherwise, template mixins will do:

    mixin template declare_a() {
        int a; // or any code, even `mixin("int a;");`
    }

    int func() {
        mixin declare_a;
        return a;
    }

Daniel Kozák <kozzi11@gmail.com> napsal Pá, led 13, 2017 v 10∶29 :
> André Puel via Digitalmars-d <digitalmars-d@puremagic.com> napsal Pá, led 13, 2017 v 10∶15 :
>> One thing that I miss sometimes when doing meta programming is being able to hide that a function should be called with mixin.
>> 
>> For example (pardon my lack of creativity):
>> 
>>     // Instead of
>>     string declare_a() {
>>         return "int a;"
>>     }
>> 
>>     int func() {
>>         mixin(declare_a);
>>         return a;
>>     }
>> 
>>     // Could we have?
>>     mixin declare_a() {
>>         return "int a;";
>>     }
>> 
>>     int func() {
>>         declare_a;
>>         return a;
>>     }
>> 
>> I think this could be useful when one is creating Idiom and Patterns, you could hide implementations details.
> 
> You can do this:
> 
> mixin template declare_a()
> {
>     int a;
> }
> 
> int func()
> {
>     mixin declare_a;
>     return a;
> }
> 
> but there is no way to exclude mixin before calling declare_a, there is a good reason for that (it is really important to be able to tell when you use mixin and when not)

Right now you can even use
template declare_a() {...}

there is no difference between template and mixin template

Daniel Kozák <kozzi11@gmail.com> napsal Pá, led 13, 2017 v 10∶32 :
> Daniel Kozák <kozzi11@gmail.com> napsal Pá, led 13, 2017 v 10∶29 :
>> André Puel via Digitalmars-d <digitalmars-d@puremagic.com> napsal Pá, led 13, 2017 v 10∶15 :
>>> One thing that I miss sometimes when doing meta programming is being able to hide that a function should be called with mixin.
>>> 
>>> For example (pardon my lack of creativity):
>>> 
>>>     // Instead of
>>>     string declare_a() {
>>>         return "int a;"
>>>     }
>>> 
>>>     int func() {
>>>         mixin(declare_a);
>>>         return a;
>>>     }
>>> 
>>>     // Could we have?
>>>     mixin declare_a() {
>>>         return "int a;";
>>>     }
>>> 
>>>     int func() {
>>>         declare_a;
>>>         return a;
>>>     }
>>> 
>>> I think this could be useful when one is creating Idiom and Patterns, you could hide implementations details.
>> 
>> You can do this:
>> 
>> mixin template declare_a()
>> {
>>     int a;
>> }
>> 
>> int func()
>> {
>>     mixin declare_a;
>>     return a;
>> }
>> 
>> but there is no way to exclude mixin before calling declare_a, there is a good reason for that (it is really important to be able to tell when you use mixin and when not)
> 
> Right now you can even use
> template declare_a() {...}
> 
> there is no difference between template and mixin template

in this context, AFAIK you can not use mixin template like a normal template but you can use non mixin template like a mixin template

On Friday, 13 January 2017 at 21:29:28 UTC, Daniel Kozák wrote:
> André Puel via Digitalmars-d <digitalmars-d@puremagic.com> napsal Pá, led 13, 2017 v 10∶15 :
>> One thing that I miss sometimes when doing meta programming is being able to hide that a function should be called with mixin.
>> 
>> For example (pardon my lack of creativity):
>> 
>>     // Instead of
>>     string declare_a() {
>>         return "int a;"
>>     }
>> 
>>     int func() {
>>         mixin(declare_a);
>>         return a;
>>     }
>> 
>>     // Could we have?
>>     mixin declare_a() {
>>         return "int a;";
>>     }
>> 
>>     int func() {
>>         declare_a;
>>         return a;
>>     }
>> 
>> I think this could be useful when one is creating Idiom and Patterns, you could hide implementations details.
>
> You can do this:
>
> mixin template declare_a()
> {
>     int a;
> }
>
> int func()
> {
>     mixin declare_a;
>     return a;
> }
>
> but there is no way to exclude mixin before calling declare_a, there is a good reason for that (it is really important to be able to tell when you use mixin and when not)

Could you elaborate on why you consider it important to be able to tell when you use mixin and when not?

I know C macro is a mess, but in C you don't know if you are calling a function or if it is a macro.

In D, you don't know if a member is a function call or an attribute when you access it without parenthesis:

    myObj.a; //Is it a function call or an attribute?

There are these cases where the one developing a library/framework want to lie to the programmer using it. It makes the feature seamless.

On Friday, 13 January 2017 at 22:12:55 UTC, André Puel wrote:
>
> Could you elaborate on why you consider it important to be able to tell when you use mixin and when not?

because it is something really different, so it is nice to know when you call something and when you mixin some code into curent scope.

Btw. I was on a same side as you are now (I am still in some way, I would prefer some shortcuts)

> In D, you don't know if a member is a function call or an attribute when you access it without parenthesis:
>
>     myObj.a; //Is it a function call or an attribute?
>

Not completly true:

class MyClass
{
    int a;
    void b() {}
}

void main()
{
    auto myObj = new MyClass;
    myObj.a; // this does not compile
    myObj.b;
}

On Friday, 13 January 2017 at 23:13:43 UTC, Daniel Kozak wrote:
> On Friday, 13 January 2017 at 22:12:55 UTC, André Puel wrote:
>>
>> Could you elaborate on why you consider it important to be able to tell when you use mixin and when not?
>
> because it is something really different, so it is nice to know when you call something and when you mixin some code into curent scope.

Yes, please, elaborate on that. Why is it really different? What are your thoughts on C macros?

>
> Btw. I was on a same side as you are now (I am still in some way, I would prefer some shortcuts)
>
>> In D, you don't know if a member is a function call or an attribute when you access it without parenthesis:
>>
>>     myObj.a; //Is it a function call or an attribute?
>>
>
> Not completly true:
>
> class MyClass
> {
>     int a;
>     void b() {}
> }
>
> void main()
> {
>     auto myObj = new MyClass;
>     myObj.a; // this does not compile
>     myObj.b;
> }

I meant the property pattern. You access an attribute and it could be a direct access in the memory or it could be a request to a remote database. One happens instantly, the other got a lot of complex things in the way. You could even get a thrown exception by just accessing an "attribute".

V Sat, 14 Jan 2017 01:28:51 +0000
André Puel via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> On Friday, 13 January 2017 at 23:13:43 UTC, Daniel Kozak wrote:
> > On Friday, 13 January 2017 at 22:12:55 UTC, André Puel wrote:
> >>
> >> Could you elaborate on why you consider it important to be able to tell when you use mixin and when not?
> >
> > because it is something really different, so it is nice to know when you call something and when you mixin some code into curent scope.
> 
> Yes, please, elaborate on that. Why is it really different? What are your thoughts on C macros?
> 
> >
> > Btw. I was on a same side as you are now (I am still in some
> > way, I would prefer some shortcuts)
> > 
> >> In D, you don't know if a member is a function call or an attribute when you access it without parenthesis:
> >>
> >>     myObj.a; //Is it a function call or an attribute?
> >> 
> >
> > Not completly true:
> >
> > class MyClass
> > {
> >     int a;
> >     void b() {}
> > }
> >
> > void main()
> > {
> >     auto myObj = new MyClass;
> >     myObj.a; // this does not compile
> >     myObj.b;
> > }
> 
> I meant the property pattern. You access an attribute and it could be a direct access in the memory or it could be a request to a remote database. One happens instantly, the other got a lot of complex things in the way. You could even get a thrown exception by just accessing an "attribute".

I do not like C macros.

It is different because when anyone see something like this:

someNameOfFunction();

He or she would expect that this call something and it could not interact with current scope (declare new local variables, change theirs values and so on).

but if we allow use same call convention for mixins we end up with something like this

string someMixin()
{
    return `a = 5;`;
}

void main()
{
    import std.stdio;
    int a = 4;
    someMixin();
    writeln(a); // wow 5 insted of 4
}

right now when I see

mixin(someMixin());

I know I need to introspect someMixin to be sure what can happend