www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Target typed new expressions for D?

reply sighoya <sighoya gmail.com> writes:
Relates to the following:

https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions

What do you think about?

I like it more than `auto` inference. You have an explicit 
invariant, and the constructor takes the invariant into account 
for value construction.

I think, however, that using `new` in D isn't possible anymore, 
maybe some different keyword.

Is this at all possible with templates now or did we suffer from 
missing return type deduction?
Apr 30
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 30 April 2021 at 16:20:13 UTC, sighoya wrote:
 Relates to the following:

 https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions

 What do you think about?

 I like it more than `auto` inference. You have an explicit 
 invariant, and the constructor takes the invariant into account 
 for value construction.

 I think, however, that using `new` in D isn't possible anymore, 
 maybe some different keyword.

 Is this at all possible with templates now or did we suffer 
 from missing return type deduction?
Lol, that's kinda cute. Maybe you could even omit the type and let the compiler match, like auto p = new(2,5) 😁 (p is Point for example),I would never write code like that tho. get completion for the type so..
Apr 30
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 April 2021 at 16:20:13 UTC, sighoya wrote:
 Relates to the following:

 https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions

 What do you think about?
I think it is kinda pointless, to be honest. I would rather see overloading on return types, then you could infer template parameters based on the inferred return type, that would be very cool.
Apr 30
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 30 April 2021 at 16:20:13 UTC, sighoya wrote:
 Relates to the following:

 https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions

 What do you think about?

 I like it more than `auto` inference. You have an explicit 
 invariant, and the constructor takes the invariant into account 
 for value construction.

 I think, however, that using `new` in D isn't possible anymore, 
 maybe some different keyword.

 Is this at all possible with templates now or did we suffer 
 from missing return type deduction?
fry regarding improvements to d. -Alex
Apr 30
prev sibling next sibling parent user1234 <user1234 12.de> writes:
On Friday, 30 April 2021 at 16:20:13 UTC, sighoya wrote:
 Relates to the following:

 https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions

 What do you think about?

 I like it more than `auto` inference. You have an explicit 
 invariant, and the constructor takes the invariant into account 
 for value construction.
This is not really comparable to `auto`. `auto` works because the expression type is known. targeted typing is actually the exact opposite.
 I think, however, that using `new` in D isn't possible anymore, 
 maybe some different keyword.

 Is this at all possible with templates now or did we suffer 
 from missing return type deduction?
It's totally possible to mimic the feature without templates. In D a possible implementation would be to add a `Type targetedTypingHint` member to `Scope`. The hint would be used when encountering an `AutoExpr`. The AutoExp would be ```ebnf AutoExp ::= 'auto' '(' Arguments ')' ``` to keep consistent with the uniform construction syntax. So to ```d Point p = auto(3, 5); //^hint ^AutoExp Class c = new auto(); //^hint ^NewExp ^AutoExp ``` But TBH I dont see much use cases.
Apr 30
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Friday, 30 April 2021 at 16:20:13 UTC, sighoya wrote:
 Relates to the following:

 https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions

 What do you think about?
I'm not a fan of expressions that require context to determine their type. D already has a few of these for built-in types; for example: int[] a1 = [1, 2, 3]; double[] a2 = [1, 2, 3]; The issue is that, while `[1, 2, 3]` can be either an `int[]` or a `double[]` in "normal" code, it's *always* an `int[]` in generic code. So if you write something as simple as int[3] a1 = [1, 2, 3].staticArray; double[3] a2 = [1, 2, 3].staticArray; ...you get a type error: Error: cannot implicitly convert expression staticArray([1, 2, 3]) of type int[3] to double[]
Apr 30
next sibling parent russhy <russhy gmail.com> writes:

May 01
prev sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Saturday, 1 May 2021 at 00:13:08 UTC, Paul Backus wrote:
 On Friday, 30 April 2021 at 16:20:13 UTC, sighoya wrote:
 Relates to the following:

 https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions

 What do you think about?
I'm not a fan of expressions that require context to determine their type. D already has a few of these for built-in types; for example: ```D int[] a1 = [1, 2, 3]; double[] a2 = [1, 2, 3]; ``` The issue is that, while `[1, 2, 3]` can be either an `int[]` or a `double[]` in "normal" code, it's *always* an `int[]` in generic code. So if you write something as simple as ```D int[3] a1 = [1, 2, 3].staticArray; double[3] a2 = [1, 2, 3].staticArray; ``` ...you get a type error: Error: cannot implicitly convert expression staticArray([1, 2, 3]) of type int[3] to double[]
Have you ever seen this beauty: ```D int[] xs = [ 2: 3, 0: 1 ]; assert(xs == [1, 0, 3]); ``` Notice how the size is not clear, like, at all! In my mind-model, literals are not “expressions that require context to determine their type” but rather have their own type that's not spelled-out in any way, but has clearly defined operations, especially implicit casts. `typeof` won't infer that special type, quite to the contrary, `typeof` will give you a reasonably general type for the literal. If `lit` is a literal, it can happen that, as an expression, using `lit` alone works, but `(cast(typeof(lit)) lit)` will fail: ```D int[] xs = cast(typeof([ 2: 3, 0: 1 ]))[ 2: 3, 0: 1 ]; // error ``` For that reason, one cannot refactor literals into enums like an idiot because enums must have a spelled-out type and `enum varName = expr;` is identical to `enum typeof(expr) varName = expr;`. ```D enum lit = [ 2: 3, 0: 1 ]; int[] xs = lit; // error: cannot implicitly convert ... `int[int]` to `int[]` ``` I don't even think _polysemous_ values (learned the term recently) are a bad idea, they're _practically useful_ in many cases. I just think the D spec should be more open about it. Before I forget it: `[ 2: 3, 1 ]` works as an expression for `int[]`, but not for `int[int]`, and `typeof([ 2: 3, 1 ])` does not compile and neither does D infer a template type for it. (It's D's version of “Initializer lists have no type!” by Scott Meyers[¹](https://www.youtube.com/watch?v=KAWA1DuvCnQ).) Worse, even if a slice type is hinted, it won't compile: ```D void f(T)(T[]) { pragma(msg, T); } f([ 2: 3, 1 ]); // expect: T == int, but error ```
May 03