proposal: @mixin functions to auto-mixin at call site

Timothee Cour thelastmammoth at gmail.com
Tue Sep 3 01:23:45 PDT 2013


On Mon, Sep 2, 2013 at 10:11 PM, monarch_dodra <monarchdodra at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130903/db57ddea/attachment.html>


More information about the Digitalmars-d mailing list