www.digitalmars.com         C & C++   DMDScript  

digitalmars.dip.ideas - Avoid boilerplate code for member initialization

reply Matthias =?UTF-8?B?Um/Dn215?= <matti731140 gmx.net> writes:
Hi,

code like that can be found in many projects:

     class Person
     {
         string firstName;
         string lastName;

         this(string f, string l)
         {
             firstName = f;
             lastName = l;

             //do some more constructor logic
         }
     }

I suggest introducing a new keyword "member" which assigns the 
members implicitly:

     class Person
     {
         string firstName;
         string lastName;

         this(member firstName, member lastName)
         {
             //do some more constructor logic
         }
     }

That should be supported for constructors, and I think that 
supporting it for functions would also be a good idea.
Mar 29
next sibling parent reply Sergey <kornburn yandex.ru> writes:
On Sunday, 29 March 2026 at 17:21:21 UTC, Matthias Roßmy wrote:

 Hi,

 code like that can be found in many projects:

     class Person
     {
         string firstName;
         string lastName;

         this(string f, string l)
         {
             firstName = f;
             lastName = l;

             //do some more constructor logic
         }
     }

 I suggest introducing a new keyword "member" which assigns the 
 members implicitly:

     class Person
     {
         string firstName;
         string lastName;

         this(member firstName, member lastName)
         {
             //do some more constructor logic
         }
     }

 That should be supported for constructors, and I think that 
 supporting it for functions would also be a good idea.


thanks
please no
Mar 29
parent reply Matthias =?UTF-8?B?Um/Dn215?= <matti731140 gmx.net> writes:
On Sunday, 29 March 2026 at 18:17:07 UTC, Sergey wrote:

 thanks
 please no


Please explain why!
Mar 29
parent reply Sergey <kornburn yandex.ru> writes:
On Sunday, 29 March 2026 at 18:24:09 UTC, Matthias Roßmy wrote:

 On Sunday, 29 March 2026 at 18:17:07 UTC, Sergey wrote:

 thanks
 please no


 Please explain why!


Check this slides and talk from last Dconf
https://dconf.org/2025/slides/korpel.pdf

So the answer: adding this new keyword doesn't worth the value it 
is bringing to the language.
Mar 29
parent reply user1234 <user1234 12.de> writes:
On Sunday, 29 March 2026 at 18:30:24 UTC, Sergey wrote:

 On Sunday, 29 March 2026 at 18:24:09 UTC, Matthias Roßmy wrote:

 On Sunday, 29 March 2026 at 18:17:07 UTC, Sergey wrote:

 thanks
 please no


 Please explain why!


 Check this slides and talk from last Dconf
 https://dconf.org/2025/slides/korpel.pdf

 So the answer: adding this new keyword doesn't worth the value 
 it is bringing to the language.


Yes but we can imagine a special syntax, for example

```d
class Person
{
     string name;
     this(string this.name)
     {
     }
}
```

or even just `.name`.
Mar 29
next sibling parent Kapendev <alexandroskapretsos gmail.com> writes:
On Sunday, 29 March 2026 at 19:03:20 UTC, user1234 wrote:

 On Sunday, 29 March 2026 at 18:30:24 UTC, Sergey wrote:

 On Sunday, 29 March 2026 at 18:24:09 UTC, Matthias Roßmy wrote:

 On Sunday, 29 March 2026 at 18:17:07 UTC, Sergey wrote:

 thanks
 please no


 Please explain why!


 Check this slides and talk from last Dconf
 https://dconf.org/2025/slides/korpel.pdf

 So the answer: adding this new keyword doesn't worth the value 
 it is bringing to the language.


 Yes but we can imagine a special syntax, for example

 ```d
 class Person
 {
     string name;
     this(string this.name)
     {
     }
 }
 ```

 or even just `.name`.


That is similar to how Dart does it, but without the type there.

Having a bit of friction on this part is not that bad though. How 
often do you write ctors? And for types that are not vectors you 
will usually want more than to just set x to x and y to y. I say 
it's not worth the change.
Mar 29
prev sibling parent reply Matthias =?UTF-8?B?Um/Dn215?= <matti731140 gmx.net> writes:
On Sunday, 29 March 2026 at 19:03:20 UTC, user1234 wrote:

 Yes but we can imagine a special syntax, for example

 ```d
 class Person
 {
     string name;
     this(string this.name)
     {
     }
 }
 ```

 or even just `.name`.


You are right, a special syntax is probably better than defining 
a new keyword. But the redundant type should be omitted:

     class Person
     {
         string name;

         this(this.name)
         {
             //some more constructor logic
         }
     }
Mar 30
parent reply user1234 <user1234 12.de> writes:
On Monday, 30 March 2026 at 07:55:28 UTC, Matthias Roßmy wrote:

 [...]
 But the redundant type should be omitted:
 [...]


Not necessarily because the type of the parameter can mismatch 
with the member's one but later, in the body, the auto-generated 
AssignExp can be semantically valid if there's a possible 
implicit conversion.
Mar 30
parent reply Matthias =?UTF-8?B?Um/Dn215?= <matti731140 gmx.net> writes:
On Monday, 30 March 2026 at 10:48:22 UTC, user1234 wrote:

 On Monday, 30 March 2026 at 07:55:28 UTC, Matthias Roßmy wrote:
 Not necessarily because the type of the parameter can mismatch 
 with the member's one but later, in the body, the 
 auto-generated AssignExp can be semantically valid if there's a 
 possible implicit conversion.


But then the implicit conversion could also be made when some 
expression is converted to the parameter. I don't see any use 
case for having a different type for the parameter. And if it 
would be really needed in a very rare case, normal parameters 
with an assign expression in the body can still be used.
Mar 30
parent user1234 <user1234 12.de> writes:
On Monday, 30 March 2026 at 11:22:15 UTC, Matthias Roßmy wrote:

 On Monday, 30 March 2026 at 10:48:22 UTC, user1234 wrote:

 On Monday, 30 March 2026 at 07:55:28 UTC, Matthias Roßmy wrote:
 Not necessarily because the type of the parameter can mismatch 
 with the member's one but later, in the body, the 
 auto-generated AssignExp can be semantically valid if there's 
 a possible implicit conversion.


 But then the implicit conversion could also be made when some 
 expression is converted to the parameter. I don't see any use 
 case for having a different type for the parameter. And if it 
 would be really needed in a very rare case, normal parameters 
 with an assign expression in the body can still be used.


You're 100% right, I just wanted to the pinpoint the fact that to 
specify the type is not always "redundant". Let's say that was 
just a detail.
Mar 30
prev sibling parent user1234 <user1234 12.de> writes:
On Sunday, 29 March 2026 at 17:21:21 UTC, Matthias Roßmy wrote:

 Hi,

 code like that can be found in many projects:

 [...]


In case someone would end up writing a DIP, I'd also like to 
mention that this feature actually solves a whole little set of 
problems related to how parameters are named.

For now this is handled using linters, for example this one check 
from PVS studio https://pvs-studio.com/en/docs/warnings/v3196/.
Mar 30