I'd like to be able to declare a function with a special @mixin property that will auto-mixin at call site:

@mixin string foo(){return some_string;}
void main(){
 foo; //behaves as mixin(foo()); if @mixin weren't provided
}

This is purely syntax sugar, as it could be done with a mixin at call site, but is very useful in a number of scenarios:

Example 1:
I wrote a string parsing function 'embed' that allows to embed variables in
current scope in a string:
void main(){
int x1=11;
double x2=2.3;
assert(mixin("variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed) ==
"variables: x1=11, x2=2.3, sum=13.3");
}
The 'embed' function parses the input string, extracts the '$' tokens (with
a proper escape mechanism) and return a string of the form 'std.conv.text(
...)' with appropriate arguments so that the string can be mixed in at call
site as above.

Without the @mixin property we have:
mixin("variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed)

With the proposed @mixin property this would simplify to: "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed

Which is simpler and easier to read than:

text("variables: x1=",x1,", x2=",x2,", sum=",x1+x2);


There are many other use cases.

If for some reason we can't have @mixin special property, can we at least
have UFCS for mixin, so that we could write:
"variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour wrote:
> I'd like to be able to declare a function with a special @mixin property
> that will auto-mixin at call site

Kenji had apparently implemented this:
https://github.com/D-Programming-Language/dmd/pull/459

But pulled out. This recent thread should sum it up:
http://forum.dlang.org/thread/yaasjclvyobpeftgwmke@forum.dlang.org

Long story short, you are basically asking for macro. If we
allowed this, than anything could actually be code injection, and
mean anything.

> If for some reason we can't have @mixin special property, can we at least
> have UFCS for mixin, so that we could write:
> "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin

I'm not sure this us very interesting (why not though), since
nothing would ever come after the mixin.

I'd still rather have "typeof" be UFCS-able:
5.typeof.stringof.writeln();

If we only got to choose 1 that is ;)

On 2013-09-03 07:11, monarch_dodra wrote:

> Kenji had apparently implemented this:
> https://github.com/D-Programming-Language/dmd/pull/459
>
> But pulled out. This recent thread should sum it up:
> http://forum.dlang.org/thread/yaasjclvyobpeftgwmke@forum.dlang.org
>
> Long story short, you are basically asking for macro. If we
> allowed this, than anything could actually be code injection, and
> mean anything.

Yes, this seems to be another workaround for some kind of AST macros.

-- 
/Jacob Carlborg

On Mon, Sep 2, 2013 at 10:11 PM, monarch_dodra <monarchdodra@gmail.com>wrote:

> On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour wrote:
>
>> I'd like to be able to declare a function with a special @mixin property that will auto-mixin at call site
>>
>
> Kenji had apparently implemented this: https://github.com/D-**Programming-Language/dmd/pull/**459<https://github.com/D-Programming-Language/dmd/pull/459>
>
> But pulled out. This recent thread should sum it up: http://forum.dlang.org/thread/**yaasjclvyobpeftgwmke@forum.**dlang.org<http://forum.dlang.org/thread/yaasjclvyobpeftgwmke@forum.dlang.org>


The last comment from Andrei in
https://github.com/D-Programming-Language/dmd/pull/459 is actually rather
supportive of such feature, and seemed to encourage a more thorough
discussion which never happened (AFAIK).
And unlike what is said in the thread above (last comment), the feature
indeed was implemented already, but not merged.



> Long story short, you are basically asking for macro. If we allowed this, than anything could actually be code injection, and mean anything.


No, only mixin statements and @mixin functions. And a regular function
calling a @mixin function would still be regular, eg not able to access
symbols in enclosing scope by name.
Given that properties can be queried at compile time, there is no
ambiguity. Proper tooling can reveal which statements are mixins if needed
(which doesn't imply that the language readability depends on having an
IDE).


>
>  If for some reason we can't have @mixin special property, can we at least
>> have UFCS for mixin, so that we could write:
>> "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin
>>
>
> I'm not sure this us very interesting (why not though), since nothing would ever come after the mixin.
>

What do you mean by "nothing would ever come after the mixin" ? You can have: some_string.embed.mixin.writeln;

Simple use case:
or: assert(foo(x)==bar(y), "error with $(foo(x)) and $(bar(y)) ".embed);

I'd still rather have "typeof" be UFCS-able:
> 5.typeof.stringof.writeln();
>
> If we only got to choose 1 that is ;)
>

Features should be orthogonal unless there's a good reason not to. IMO, assert, typeof, mixin, etc should all be UFCS-able. But this has been brought up many times before.

On Tuesday, 3 September 2013 at 08:23:57 UTC, Timothee Cour wrote:
>> Long story short, you are basically asking for macro. If we
>> allowed this, than anything could actually be code injection, and
>> mean anything.
>
>
> No, only mixin statements and @mixin functions. And a regular function
> calling a @mixin function would still be regular, eg not able to access
> symbols in enclosing scope by name.

But that sill implies knowing exactly *what* is called, eg knowing the documentation of everything that is used, as opposed to just knowing "that *looks* like a function call that *does* something or other", but not worrying about it more than that.

Allowing implicit mixin adds an entire extra level of "dereference" when reading wode.

>>
>>  If for some reason we can't have @mixin special property, can we at least
>>> have UFCS for mixin, so that we could write:
>>> "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin
>>>
>>
>> I'm not sure this us very interesting (why not though), since
>> nothing would ever come after the mixin.
>>
>
> What do you mean by "nothing would ever come after the mixin" ?
> You can have: some_string.embed.mixin.writeln;

Hadn't thought of that.

Was objecting in previous thread and have not changed my mind - it is unhygienic and mostly useless.

On 9/3/13 2:11 AM, monarch_dodra wrote:
> On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour wrote:
>> I'd like to be able to declare a function with a special @mixin property
>> that will auto-mixin at call site
>
> Kenji had apparently implemented this:
> https://github.com/D-Programming-Language/dmd/pull/459
>
> But pulled out. This recent thread should sum it up:
> http://forum.dlang.org/thread/yaasjclvyobpeftgwmke@forum.dlang.org
>
> Long story short, you are basically asking for macro. If we
> allowed this, than anything could actually be code injection, and
> mean anything.
>
>> If for some reason we can't have @mixin special property, can we at least
>> have UFCS for mixin, so that we could write:
>> "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin
>
> I'm not sure this us very interesting (why not though), since
> nothing would ever come after the mixin.
>
> I'd still rather have "typeof" be UFCS-able:
> 5.typeof.stringof.writeln();
>
> If we only got to choose 1 that is ;)

"Today if anyone writes or sees sees mixin(stuff) they are well warned that arbitrary code generation is taking place and are ready to deal with the consequences."

When you do "import foo.bar" you are importing arbitrary code... If you are not sure what that does, you go look it up. And it's the same for implicit mixins. I don't see the issue at all...

On Tuesday, 3 September 2013 at 18:26:57 UTC, Ary Borenszweig wrote:
> On 9/3/13 2:11 AM, monarch_dodra wrote:
>> On Tuesday, 3 September 2013 at 04:15:17 UTC, Timothee Cour wrote:
>>> I'd like to be able to declare a function with a special @mixin property
>>> that will auto-mixin at call site
>>
>> Kenji had apparently implemented this:
>> https://github.com/D-Programming-Language/dmd/pull/459
>>
>> But pulled out. This recent thread should sum it up:
>> http://forum.dlang.org/thread/yaasjclvyobpeftgwmke@forum.dlang.org
>>
>> Long story short, you are basically asking for macro. If we
>> allowed this, than anything could actually be code injection, and
>> mean anything.
>>
>>> If for some reason we can't have @mixin special property, can we at least
>>> have UFCS for mixin, so that we could write:
>>> "variables: x1=$x1, x2=$x2, sum=$(x1+x2)".embed.mixin
>>
>> I'm not sure this us very interesting (why not though), since
>> nothing would ever come after the mixin.
>>
>> I'd still rather have "typeof" be UFCS-able:
>> 5.typeof.stringof.writeln();
>>
>> If we only got to choose 1 that is ;)
>
> "Today if anyone writes or sees sees mixin(stuff) they are well warned that arbitrary code generation is taking place and are ready to deal with the consequences."
>
> When you do "import foo.bar" you are importing arbitrary code... If you are not sure what that does, you go look it up. And it's the same for implicit mixins. I don't see the issue at all...

But "import" is also explicit. Do you think it would be a good idea that a function be allowed to implicitly import things just by calling it? Because that basically what implicit mixin allows.

On 9/3/13, Ary Borenszweig <ary@esperanto.org.ar> wrote:
> When you do "import foo.bar" you are importing arbitrary code...

You are importing symbols. And when you do "foo()" you know you're
calling a function. With the change, you'll never know what foo()
does.

This feature is never going to fly, but people are just going to argue this forever..

On 2013-09-03 21:05, Andrej Mitrovic wrote:

> You are importing symbols. And when you do "foo()" you know you're
> calling a function. With the change, you'll never know what foo()
> does.
>
> This feature is never going to fly, but people are just going to argue
> this forever..

With properties you never know if you're invoking a method or accessing a field:

foo.data; // call method or access field?

-- 
/Jacob Carlborg