HS Teoh why u always gotta go and break the forum

Walter,

what do you think about allowing mixins to work with parameter list construction?

Currently you cannot generate code unless it is syntactically complete on its own, this disallows parameter list construction even for syntactically correct parameter lists.

The other failure point of mixins is when stringing together function calls with the dot, eg A.mixin(MYFUNC).foo;

A whole lot more could be done with mixins if restrictions were relaxed just a bit more in a few key areas. I don't see too much obfuscation happening so long as the allowable constructs are carefully limited and cannot be manipulated in ways that factor into the concerns you mentioned previously.

To make it clear we could have a special parammixin() and dotmixin() or whatever to ensure there's no possibility of confusion.

--rt

On 11/17/2013 09:48 PM, Walter Bright wrote:
>
> It was this by Timon Gehr essentially posting why lazy parameters
> weren't good enough:
>
>> On 11/13/2013 08:25 PM, Walter Bright wrote:
>>>>
>>>
>>> Ah, found the code:
>>>
>>> void ifthen(bool cond, lazy void dg)
>>> {
>>>      if (cond)
>>>          dg();
>>> }
>>
>> int foo(int x){
>>     ifthen(!x, return 2); // uh oh
>>     return 3;
>> }
>

This code was just supposed to demonstrate that ifthen is not actually a "statement" work-alike as claimed in a previous post.

On 11/17/2013 08:41 PM, Simen Kjærås wrote:
>
> I decided to abandon sanity. Luckily, only for the named parameters. I
> now have this code working:
>
>
> void test(int a, int b = 2, string c = "foo", int d = 14) {
> }
>
> alias test2 = nameify!test;
>
> void main() {
>      test2(1, Args.d = 4, Args.c = "bar");
> }
>
> With reasonable error messages for duplicate and missing parameters, as
> well as type mismatches.
> ...

Still missing overload resolution. :o)

On 17.11.2013 23:21, Timon Gehr wrote:
> On 11/17/2013 08:41 PM, Simen Kjærås wrote:
>>
>> I decided to abandon sanity. Luckily, only for the named parameters. I
>> now have this code working:
>>
>>
>> void test(int a, int b = 2, string c = "foo", int d = 14) {
>> }
>>
>> alias test2 = nameify!test;
>>
>> void main() {
>>      test2(1, Args.d = 4, Args.c = "bar");
>> }
>>
>> With reasonable error messages for duplicate and missing parameters, as
>> well as type mismatches.
>> ...
>
> Still missing overload resolution. :o)

Please don't tempt me. :p

-- 
  Simen

On 11/17/2013 1:58 PM, Timon Gehr wrote:
> This code was just supposed to demonstrate that ifthen is not actually a
> "statement" work-alike as claimed in a previous post.

Ok, my apologies.

On Sunday, 17 November 2013 at 20:48:15 UTC, Walter Bright wrote:
>> That never was in the DIP.
>
> It was this by Timon Gehr essentially posting why lazy parameters weren't good enough:
>
>> On 11/13/2013 08:25 PM, Walter Bright wrote:
>>>>
>>>
>>> Ah, found the code:
>>>
>>> void ifthen(bool cond, lazy void dg)
>>> {
>>>     if (cond)
>>>         dg();
>>> }
>>
>> int foo(int x){
>>    ifthen(!x, return 2); // uh oh
>>    return 3;
>> }

As I understand it, Timon choosed that syntax simply to demonstrate the limitation of your proposal using a similar syntax. Not to propose a syntax.

On 11/17/2013 7:14 PM, deadalnix wrote:
> As I understand it, Timon choosed that syntax simply to demonstrate the
> limitation of your proposal using a similar syntax. Not to propose a syntax.

Ok, then I'm not seeing what AST macros do that lazy parameters / template overloading / mixin templates do not?

On Monday, 18 November 2013 at 05:05:02 UTC, Walter Bright wrote:
> On 11/17/2013 7:14 PM, deadalnix wrote:
>> As I understand it, Timon choosed that syntax simply to demonstrate the
>> limitation of your proposal using a similar syntax. Not to propose a syntax.
>
> Ok, then I'm not seeing what AST macros do that lazy parameters / template overloading / mixin templates do not?

2 things. First, they can act on statement or declaration. Simply not with the proposed syntax. Second they can reflect what is passed as argument and act accordingly, when the lazy expression solution cannot.

On 2013-11-17 14:36, Simen Kjærås wrote:

> I believe it is basically this:
>
> int bar() {
>      foo(return 3);
>      return 5;
> }
>
>
> If that program is allowed to compile, and to return 3.

I see, I guess that should work with with the DIP.

-- 
/Jacob Carlborg