digitalmars.D - Target typed new expressions for D?
- sighoya (10/10) Apr 30 2021 Relates to the following:
- Imperatorn (6/16) Apr 30 2021 Lol, that's kinda cute. Maybe you could even omit the type and
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (5/8) Apr 30 2021 I think it is kinda pointless, to be honest.
- 12345swordy (4/14) Apr 30 2021 It is a nice feature to use in c#. However there are big fish to
- user1234 (21/31) Apr 30 2021 This is not really comparable to `auto`. `auto` works because the
- Paul Backus (14/17) Apr 30 2021 I'm not a fan of expressions that require context to determine
- russhy (1/1) May 01 2021 Oh god please no, let's not copy one of the worst's C# ideas
- Q. Schroll (40/63) May 03 2021 Have you ever seen this beauty:
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 2021
Imperatorn <johan_forsberg_86 hotmail.com> 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 2021
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 2021
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 2021
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 2021
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 2021
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: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 ```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[]
May 03 2021