One of my favourite language features of Dart (other one being factory constructors) are auto-assign constructors, for example (writing it in pseudo-D):

class Person
{
  string name;
  int age;
  this(this.age, this.name);
}

would translate to

class Person
{
  string name;
  int age;
  this(int age, string name)
  {
    this.age = age;
    this.name = name;
  }
}


It saves a lot of typing in the long run when doing lots of OOP, is there a way to reproduce such behaviour using mixins? I was thinking of some interface like:

class Person
{
  string name;
  int age;
  mixin(AutoConstructor!(age, name));
}

but I don't know if that's even doable using mixins. Even cooler might be something like an annotation (feels a bit Lombok-like from Java):

@AutoConstructor
class Person
{
  string name;
  int age;
}

but I don't think it's doable in D right now.

I am not looking for code, I can try that myself, just asking if such things are possible?

On Thursday, 25 May 2017 at 08:34:54 UTC, JN wrote:
> One of my favourite language features of Dart (other one being factory constructors) are auto-assign constructors, for example (writing it in pseudo-D):
>
> class Person
> {
>   string name;
>   int age;
>   this(this.age, this.name);
> }
>
> would translate to
>
> class Person
> {
>   string name;
>   int age;
>   this(int age, string name)
>   {
>     this.age = age;
>     this.name = name;
>   }
> }
>
>
> It saves a lot of typing in the long run when doing lots of OOP, is there a way to reproduce such behaviour using mixins? I was thinking of some interface like:
>
> class Person
> {
>   string name;
>   int age;
>   mixin(AutoConstructor!(age, name));
> }
>
> but I don't know if that's even doable using mixins. Even cooler might be something like an annotation (feels a bit Lombok-like from Java):
>
> @AutoConstructor
> class Person
> {
>   string name;
>   int age;
> }
>
> but I don't think it's doable in D right now.
>
> I am not looking for code, I can try that myself, just asking if such things are possible?

Not sure about classes (I don't use them much) but structs have an automatically defined constructor. It is most definitely possible to do that with a mixin template (I remember someone recently showing autogenerating properties for readonly private members, sorry don't have a link).

The UDA approach won't work because they are there for reflection. You can generate code based on the presence (or absence) of a UDA but you can't synthesise new methods with that without forwarding from a wrapper.

On Thursday, 25 May 2017 at 08:34:54 UTC, JN wrote:
> One of my favourite language features of Dart (other one being factory constructors) are auto-assign constructors, for example (writing it in pseudo-D):
>
> class Person
> {
>   string name;
>   int age;
>   this(this.age, this.name);
> }
>
> would translate to
>
> class Person
> {
>   string name;
>   int age;
>   this(int age, string name)
>   {
>     this.age = age;
>     this.name = name;
>   }
> }
>
>
> It saves a lot of typing in the long run when doing lots of OOP, is there a way to reproduce such behaviour using mixins? I was thinking of some interface like:
>
> class Person
> {
>   string name;
>   int age;
>   mixin(AutoConstructor!(age, name));
> }
>

The syntax would be mixin(AutoConstructor!(Person, "age", "name")), as
1. the compiler will throw you a `need 'this' to access member AutoConstructor` if you try to pass the arguments the way you did in the above
2. to avoid having to do ugly things to then get back at the type of those arguments again you will want to pass the type of the class in.

On 05/25/2017 10:34 AM, JN wrote:
> class Person
> {
>    string name;
>    int age;
>    mixin(AutoConstructor!(age, name));
> }
[...]
> I am not looking for code, I can try that myself, just asking if such things are possible?

I know you're not asking for code, but without experimenting I wouldn't have known that this works. In the end it's surprisingly simple:

----
mixin template AutoConstructor(fields ...)
{
    this(typeof(fields) args) { fields = args; }
}

class Person
{
    string name;
    int age;
    mixin AutoConstructor!(age, name);
}

void main()
{
    auto p = new Person(42, "Arthur");
    assert(p.age == 42);
    assert(p.name == "Arthur");
}
----

On Thursday, 25 May 2017 at 10:42:00 UTC, ag0aep6g wrote:
> On 05/25/2017 10:34 AM, JN wrote:
>> class Person
>> {
>>    string name;
>>    int age;
>>    mixin(AutoConstructor!(age, name));
>> }
> [...]
>> I am not looking for code, I can try that myself, just asking if such things are possible?
>
> I know you're not asking for code, but without experimenting I wouldn't have known that this works. In the end it's surprisingly simple:
>
> ----
> mixin template AutoConstructor(fields ...)
> {
>     this(typeof(fields) args) { fields = args; }
> }
> ----

Be aware, though, that constructors mixed in via a mixin template behave differently with regards to overloading[1].

[1] https://issues.dlang.org/show_bug.cgi?id=11500

On 05/25/2017 12:52 PM, Moritz Maxeiner wrote:
> Be aware, though, that constructors mixed in via a mixin template behave differently with regards to overloading[1].
> 
> [1] https://issues.dlang.org/show_bug.cgi?id=11500

Of course it couldn't be that simple :(

Adam's workaround (`alias __ctor = mixin_thing.__ctor;`) might be workable, though.

If that makes the usage too verbose, then a string mixin is the way to go, I guess. It's immune to issue 11500, but AutoConstructor isn't as nice to look at:

----
static string AutoConstructor(fields ...)()
{
    import std.meta: staticMap;
    import std.traits: fullyQualifiedName;
    import std.string: join;

    enum fqns = staticMap!(fullyQualifiedName, fields);
    auto fields_str = "std.meta.AliasSeq!(" ~ [fqns].join(", ") ~ ")";

    return "
        static import std.meta;
        this(typeof(" ~ fields_str ~ ") args)
        {
            " ~ fields_str ~ " = args;
        }
    ";
}

class Person
{
    string name;
    int age;
    mixin(AutoConstructor!(age, name));
    this(float f) {}
}

void main()
{
    auto p = new Person(42, "Arthur");
    assert(p.age == 42);
    assert(p.name == "Arthur");
}
----

Weird: AutoConstructor needs to be static. Doesn't make sense to me. Looks like a compiler bug.

On Thursday, 25 May 2017 at 11:31:43 UTC, ag0aep6g wrote:
> On 05/25/2017 12:52 PM, Moritz Maxeiner wrote:
>> [...]
>
> Of course it couldn't be that simple :(
>
> Adam's workaround (`alias __ctor = mixin_thing.__ctor;`) might be workable, though.
>
> [...]

FWIW if this is properly working (e.g. with 11500 fixed), it would make a lot of sense to me to add it to Phobos as this looks like a very useful piece (useful enough maybe even try a DIP to get it into D).

On Thursday, 25 May 2017 at 11:31:43 UTC, ag0aep6g wrote:
> On 05/25/2017 12:52 PM, Moritz Maxeiner wrote:
>> Be aware, though, that constructors mixed in via a mixin template behave differently with regards to overloading[1].
>> 
>> [1] https://issues.dlang.org/show_bug.cgi?id=11500
>
> Of course it couldn't be that simple :(
>
> Adam's workaround (`alias __ctor = mixin_thing.__ctor;`) might be workable, though.
>
> If that makes the usage too verbose, then a string mixin is the way to go, I guess. It's immune to issue 11500, but AutoConstructor isn't as nice to look at:
>
> ----
> static string AutoConstructor(fields ...)()
> {
>     [...]
> }
> ----
>
> Weird: AutoConstructor needs to be static. Doesn't make sense to me. Looks like a compiler bug.

Nice. If you look at my initial reply to OP you'll see that I mentioned that error and I worked around it differently (worse than you). Didn't know that static would fix that (and I don't understand why it does), but thanks for the info!

On Thursday, 25 May 2017 at 12:35:57 UTC, Moritz Maxeiner wrote:
> On Thursday, 25 May 2017 at 11:31:43 UTC, ag0aep6g wrote:
>> On 05/25/2017 12:52 PM, Moritz Maxeiner wrote:
>>> Be aware, though, that constructors mixed in via a mixin template behave differently with regards to overloading[1].
>>> 
>>> [1] https://issues.dlang.org/show_bug.cgi?id=11500
>>
>> Of course it couldn't be that simple :(
>>
>> Adam's workaround (`alias __ctor = mixin_thing.__ctor;`) might be workable, though.
>>
>> If that makes the usage too verbose, then a string mixin is the way to go, I guess. It's immune to issue 11500, but AutoConstructor isn't as nice to look at:
>>
>> ----
>> static string AutoConstructor(fields ...)()
>> {
>>     [...]
>> }
>> ----
>>
>> Weird: AutoConstructor needs to be static. Doesn't make sense to me. Looks like a compiler bug.
>
> Nice. If you look at my initial reply to OP you'll see that I mentioned that error and I worked around it differently (worse than you). Didn't know that static would fix that (and I don't understand why it does), but thanks for the info!

After thinking about this a bit I think I know why it doesn't work without static and it's not a compiler bug. Since

---
string AutoConstructor(fields ...)() {}
---

is just syntax sugar for
---
template AutoConstructor(fields ...)
{
    string AutoConstructor() {}
}
---

instantiating the template AutoConstructor inside class Person gives you a non-static member function AutoConstructor of class Person, so obviously we need an instance of Person to call it on. Or make it a static member function.

On 05/25/2017 03:13 PM, Moritz Maxeiner wrote:
> After thinking about this a bit I think I know why it doesn't work without static and it's not a compiler bug. Since
> 
> ---
> string AutoConstructor(fields ...)() {}
> ---
> 
> is just syntax sugar for
> ---
> template AutoConstructor(fields ...)
> {
>      string AutoConstructor() {}
> }
> ---
> 
> instantiating the template AutoConstructor inside class Person gives you a non-static member function AutoConstructor of class Person, so obviously we need an instance of Person to call it on. Or make it a static member function.

I don't think that's it.

The function itself is not mixed into the class. It's called and the result is mixed in. I don't see how it makes sense if the compiler tries to turn the called function into a method.