On Sunday, 18 November 2018 at 19:09:16 UTC, Trailzz wrote:
> This situation happens *very* often in object oriented programming:
> ```
> this(string a, int b, char c, float d, uint e, bool f)
> {
>     this.a = a;
>     this.b = b;
>     this.c = c;
>     this.d = d;
>     this.e = e;
>     this.f = f;
> }
> ```
>
> It would save a lot of code bloat if there was a simpler syntax for this, perhaps something like this:
> ```
> this(string this.a, int this.b, char this.c, float this.d, uint this.e, bool this.f)
> {
> }
> ```
>
> It would be very easy to infer the types here, so this could also work
> ```
> this(this.a, this.b, this.c, this.d, this.e, this.f)
> {
> }
> ```
>
> I'm not sure exactly what the syntax would be like, but I just wanted to know what other people think about this. Would it be worth creating a DIP for this?

You can use my boilerplate library https://code.dlang.org/packages/boilerplate to automatically generate constructors for pod classes. Just mixin(GenerateThis);

On Sunday, 18 November 2018 at 19:59:27 UTC, Timon Gehr wrote:
> class C{
>     string a;
>     int b;
>     char c;
>     float d;
>     uint e;
>     bool f;
>     this(string a, int b, char c, float d, uint e, bool f){
>         mixin(assignFields);
>     }
> }

It is not good when there is one parameter, you probably will write usual assignment for readability. In most of cases - 1 or 2 parameters - this solution improves nothing.

On the other hand, members with _ or m_ in the name will force parameters to have the same names in the OP syntax.

On Sunday, 18 November 2018 at 19:09:16 UTC, Trailzz wrote:
>
> I'm not sure exactly what the syntax would be like, but I just wanted to know what other people think about this. Would it be worth creating a DIP for this?


Well, let's step back a bit, from the so called 'code bloat', and have a look at the definition of a function:

return-type function-name(parameter declarations, if any)
{
  declarations
  statements
}

What you are suggesting, is, in order to save a few keystrokes, that D changes the definition of a function (or a constructor function in this case).

No language that has functions allows you do initialize variables in the section where you declare your parameters - at least, no language that I am aware of.

Lets not surprise newcomers to D, anymore than they are already going to be surprised.

Its bad enough you can't have a private member within a module!

Initializing variables in the parameter section of the function would be a step too far.

On 11/18/18 3:06 PM, Trailzz wrote:
> On Sunday, 18 November 2018 at 19:59:27 UTC, Timon Gehr wrote:
>> On 18.11.18 20:52, Trailzz wrote:
>>> On Sunday, 18 November 2018 at 19:47:26 UTC, Jacob Carlborg wrote:
>>>> [...]
>>>
>>> This is still very clunky and hard to understand.
>>
>> ---
>> module util;
>> enum assignFields=q{{
>>     import std.traits;
>>     static foreach(x;ParameterIdentifierTuple!(__traits(parent,{})))
>>         static if(__traits(hasMember, this, x))
>>             __traits(getMember,this,x)=mixin(x);
>> }};
>> ---
>> ---
>> module app;
>> import util;
>>
>> class C{
>>     string a;
>>     int b;
>>     char c;
>>     float d;
>>     uint e;
>>     bool f;
>>     this(string a, int b, char c, float d, uint e, bool f){
>>         mixin(assignFields);
>>     }
>> }
>>
>> void main(){
>>     import std.stdio;
>>     writeln((new C("1",2,'3',4.0,5,true).tupleof));
>> }
>> ---
> 
> This is arguably more clunky than just lots of `this.foo = foo`.

Maybe you didn't notice that util module is written *once*, and then imported where used. All you would have to do is the one `mixin(assignFields)` line in the places you wanted this boiler plate.

To me, this is an elegant, simple solution, and IMO, actually nicer than any proposed language syntax changes (I find having to put `this` in front of all the parameter names just as clunky as doing the assignments).

-Steve

On Sunday, 18 November 2018 at 20:20:50 UTC, Adam D. Ruppe wrote:
> class A {
>   int a;
>   string b;
>   float c;
>
>   this(typeof(this.tupleof) args) {
>     this.tupleof = args;
>   }
> }
>
>
> auto a = new A(4, "foo", 1.5);
>
>
> Of course, that assumes none of the internal types are const, that complicates things, and it assumes you want to set them all at once. It also doesn't work quite right with inheritance, but you can make that work by combining the base class tuple if you want.
>
> Keep in mind you can also slice tuples if you want a subset of the members.

The problem with your solution is if you just want a and b assigned.

On Monday, 19 November 2018 at 16:15:38 UTC, bauss wrote:
> The problem with your solution is if you just want a and b assigned.

That's why I said you can slice tuples. Of course, slice needs them to be contiguous but still.

Though tbh I think this whole thing is folly - for pod, use struct and things just work. If your class has a group of pod stuff... use a struct!

On Monday, 19 November 2018 at 12:30:20 UTC, NoMoreBugs wrote:
> On Sunday, 18 November 2018 at 19:09:16 UTC, Trailzz wrote:
>>
>> I'm not sure exactly what the syntax would be like, but I just wanted to know what other people think about this. Would it be worth creating a DIP for this?
>
>
> Well, let's step back a bit, from the so called 'code bloat', and have a look at the definition of a function:
>
> return-type function-name(parameter declarations, if any)
> {
>   declarations
>   statements
> }
>
> What you are suggesting, is, in order to save a few keystrokes, that D changes the definition of a function (or a constructor function in this case).
>
> No language that has functions allows you do initialize variables in the section where you declare your parameters - at least, no language that I am aware of.
>

TypeScript:

class MyClass {
    constructor(
        readonly myValue: number,
        myArgument: number,
    ) {}
}

also Kotlin:

class MyClass(
    val myValue: Int,
    myArgument: String
) {}

> Lets not surprise newcomers to D, anymore than they are already going to be surprised.
>
> Its bad enough you can't have a private member within a module!
>
> Initializing variables in the parameter section of the function would be a step too far.

On Monday, 19 November 2018 at 21:36:32 UTC, Erik van Velzen wrote:
>
>
> TypeScript:
>
> class MyClass {
>     constructor(
>         readonly myValue: number,
>         myArgument: number,
>     ) {}
> }
>
> also Kotlin:
>
> class MyClass(
>     val myValue: Int,
>     myArgument: String
> ) {}
>

Well, I do not 'know' either of Typescript or Kotlin - so my statement stands correct ;-)

Of course, my argument is more about consistency, and less about how a particular language implements a constructor.

Consistency makes code easier to write, easier to understand, and easier to maintain.

Sadly, D, like many languages, lets you do the same things in any number of ways - which just places more burden on programmers. Go-lang has kinda addressed this issue..

It's also about modularity/encapsulation I guess. The function definition is really a definition of its parts, what those parts do, and how they work together to form the desired 'functionality'.

Lets keep 'the parts' - please.

-----
return-type function-name(parameter declarations, if any)
{
  declarations
  statements
}
----

On Sunday, 18 November 2018 at 19:52:48 UTC, Trailzz wrote:
> On Sunday, 18 November 2018 at 19:47:26 UTC, Jacob Carlborg wrote:
>>     this(int a, int b)
>>     {
>>         static foreach (name ; ParameterIdentifierTuple!(__ctor))
>>             __traits(getMember, this, name) = mixin(name);
>>     }
>> }
>
> This is still very clunky and hard to understand.

I'm not sure if you get it but to understand some D code, there's some amount of language features you need to know about first like mixins, stuff in std.traits and what they do... and CTFE...a few others too. Otherwise, D code might look very weird to you. But once you get it, you'll smile to D code for its modelling power. The combination of these features can be mentally tasking if you don't understand each of them.

I'll recommend the "Programming in D" book if you haven't read it already (http://ddili.org/ders/d.en/index.html).


"I can do anything! with D."

On Sunday, 18 November 2018 at 19:09:16 UTC, Trailzz wrote:
> I'm not sure exactly what the syntax would be like, but I just wanted to know what other people think about this. Would it be worth creating a DIP for this?

Personally I am a huge fan of this feature. Dart has it and I've used it a lot.