Would this be a useful construct to add to D? auto for constructor call.

Jan 23

Chris Katko

Jan 23

Jonathan M Davis

Jan 23

Jan 23

Jan 23

Jan 23

Jan 24

Jan 28

class dataGridLayerView{ int t; this(int _t){ t = _t; } } class myClass{ dataGridLayerView dataGrid; this() { dataGrid = new auto(15); // <--- new // instead of dataGrid = new dataGridLayerView(15); } }

January 22

Re: Would this be a useful construct to add to D? auto for constructor call.

Posted by Jonathan M Davis
in reply to Chris Katko

Permalink

Jonathan M Davis

Posted in reply to Chris Katko

Permalink

On Monday, January 22, 2024 11:05:28 PM MST Chris Katko via Digitalmars-d- announce wrote:
> ```D
> class dataGridLayerView{
>     int t;
>     this(int _t){
>        t = _t;
>        }
>     }
>
> class myClass{
>     dataGridLayerView dataGrid;
>
>     this()
>        {
>        dataGrid = new auto(15); // <--- new
>        // instead of
>        dataGrid = new dataGridLayerView(15);
>        }
>     }
> ```
>
> Because it seems, conceptually, the compiler should know all the details required here to simply insert the right constructor name. Basically just the reverse of:
>
> ```D
> auto t = sqrt(15);
> ```
>
> So intuitively it makes sense to me.
>
> It might even be possible to write a mixin to do this, I'm not sure.
>
> I'm no D wizard, but I don't see any obvious name or lexing conflicts/ambiguity.
>
> Cheers,
> --Chris

This is the wrong forum for questions. This is for announcements.

https://forum.dlang.org/group/general is for general discussions on D.

https://forum.dlang.org/group/learn is for asking questions about using D.

In any case, as far as your question goes, it is unlikely that a feature like that would be implemented, because expressions in D do not typically get their type from what they're assigned to. The type of the expression is determined separately from where it is used, and then it's checked to see whether it works where it's being used. There are a few exceptions (mostly having to do with initializing variables from array literals), so I don't know that the chances of adding a feature like this are zero, but I don't think that they're high.

That being said, I expect that it would be pretty easy to write a mixin to do something like that if you really wanted to. Also, if you're simply looking to not have to name the type, you could do

dataGrid = new typeof(datagrid)(15);

- Jonathan M Davis

On Tuesday, January 23, 2024 4:11:00 AM MST ryuukk_ via Digitalmars-d-announce wrote: > On Tuesday, 23 January 2024 at 06:30:08 UTC, Jonathan M Davis > > wrote: > > That being said, I expect that it would be pretty easy to write a mixin to do something like that if you really wanted to. Also, if you're simply looking to not have to name the type, you could do > > > > dataGrid = new typeof(datagrid)(15); > > > > - Jonathan M Davis > > You like to turn off people before they get the chance to develop further, this is bad > > You should try more languages, it'll be eye opener > > ``dataGrid = new typeof(datagrid)(15);`` is both, verbose and ugly > > Besides, you seem to have missed this: > > https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/ DIPs/DIP1044.md > > https://github.com/dlang/dmd/pull/14650 > > It could be expanded with structs/classes > > So your "it can't be done" argument is already wrong I never said that it couldn't be done. I said that it goes against how expressions and assignment in D normally work, so it's probably not a change that would be accepted. And the DIP and PR that you linked to have been rejected. If the OP wants to push for a change like this, then they can, and they might get lucky, but I would expect it to be rejected. Either way, there are ways to do something similar with what we already have, so I pointed them out. While you might not like a solution like using typeof, it is an option that someone can use right now regardless of what improvements we get in the future. - Jonathan M Davis

On Tuesday, 23 January 2024 at 11:11:00 UTC, ryuukk_ wrote:

On Tuesday, 23 January 2024 at 06:30:08 UTC, Jonathan M Davis wrote:

That being said, I expect that it would be pretty easy to write a mixin to do something like that if you really wanted to. Also, if you're simply looking to not have to name the type, you could do

dataGrid = new typeof(datagrid)(15);

You like to turn off people before they get the chance to develop further, this is bad

Would you like to encourage proposals/work/effort that will ultimately not be accepted? I don't. I would rather tell someone no early than tell them no later. And I agree with Jonathan, zero proposals that infer type from how they are used have been accepted by Walter, this one probably will be no different.

To the OP, I think the value of the feature needs to be more than just avoiding repeating the name of the type.

You also can do some library tricks (unfortunately this won't count as construction, but probably is fine in most cases)

auto create(T, Args...)(out T val, Args args)
{
   static if(is(T == class))
      val = new T(args);
   else static if(...) // do eveyrything else.
}

...

dataGrid.create(15);

-Steve

On 1/23/2024 8:01 AM, Steven Schveighoffer wrote: > zero proposals that infer type from how they are used have been accepted by Walter, this one probably will be no different. Types are inferred in D from the bottom up. Mixing in special cases of it being top down leads to confusion over how the type is determined.

On Wednesday, 24 January 2024 at 08:22:49 UTC, Walter Bright wrote: > On 1/23/2024 8:01 AM, Steven Schveighoffer wrote: >> zero proposals that infer type from how they are used have been accepted by Walter, this one probably will be no different. > > Types are inferred in D from the bottom up. Mixing in special cases of it being top down leads to confusion over how the type is determined. Thanks to everyone for the feedback. And sorry I selected the wrong forum. Apologies, --Chris

Forums