digitalmars.D.bugs - [Issue 10491] New: Type inference for function arguments with default value
- d-bugmail puremagic.com (33/33) Jun 27 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (11/11) Jun 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (31/31) Jun 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (30/61) Jun 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (8/9) Jun 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (11/11) Jul 02 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (16/21) Jul 02 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (15/20) Jul 02 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
- d-bugmail puremagic.com (13/13) Jul 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10491
http://d.puremagic.com/issues/show_bug.cgi?id=10491 Summary: Type inference for function arguments with default value Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: bearophile_hugs eml.cc Sometimes I have code like this: struct VeryLongNamedStruct {} void foo(in VeryLongNamedStruct x = VeryLongNamedStruct(1)) {} void main() {} Or even: void bar(in TupleFoo x = TupleFoo(TupleBar(2), TupleSpam(3))) {} In those cases something I'd like to use "auto" in the function signature for the arguments that have a default value: void foo(in auto x = VeryLongNamedStruct(1)) {} A bit more complex case: void spam(T)(const x = Foo!T(4)) {} This is not an important new enhancement request (not all enhancement requests have the same importance level), it doesn't allow to do new things, and its priority is low, but (assuming it's not too much work to implement) I think it's a handy small feature. It acts similarly to normal variable definitions, so I think there is nothing much new to learn for D programmers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 27 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491 Henning Pohl <henning still-hidden.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull CC| |henning still-hidden.de PDT --- https://github.com/D-Programming-Language/dmd/pull/2270 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 28 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491 I don't like the enhancements of this kind. Because: 1. Default argument is not so often used. Then, reduction amount of the code is very limited. 2. It breaks consistency of C-style languages that all of function parameters in function signature have their own type explicitly. 3. It would introduce one more forward reference possibility. void foo(auto a = bar()) {} // inference auto bar() { alias T = ParameterTypeTuple!foo[0]; // requires foo's complete signature return T.init; } void main() { auto x = bar(); } Already, auto return, function attribute inference has same possibility. They sometimes produces legitimate (but difficult to understand) forward reference errors. 4. `auto ref` / `in ref` is still debatable. This enhancement might have interference with it. ---- Side note: Today, issue 7152 is implemented. By that, void foo(in VeryLongNamedStruct x = VeryLongNamedStruct(1)) {} might be shorten to: void foo(in VeryLongNamedStruct x = 1) {} -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 28 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491 Thank you for the comments Kenji.1. Default argument is not so often used. Then, reduction amount of the code is very limited.I agree. This is why I said it's not an important enhancement request. It's handy, but not often.2. It breaks consistency of C-style languages that all of function parameters in function signature have their own type explicitly.I think this is not much relevant. It doesn't break valid C code.3. It would introduce one more forward reference possibility. void foo(auto a = bar()) {} // inference auto bar() { alias T = ParameterTypeTuple!foo[0]; // requires foo's complete signature return T.init; } void main() { auto x = bar(); } Already, auto return, function attribute inference has same possibility. They sometimes produces legitimate (but difficult to understand) forward reference errors.Right, the more type inference you add, the more complex is for the compiler (and sometimes for the programmer too) to understand the code and make it work. Using ParameterTypeTuple on an inferenced argument type looks like a way to stress the type inferencer.4. `auto ref` / `in ref` is still debatable. This enhancement might have interference with it."in ref" is not a problem, because this is not valid code: struct Foo { int x; } int foo(in ref Foo f = Foo(1)) {} So this is not valid code: struct Foo { int x; } int foo(in ref f = Foo(1)) {} This is currently valid: struct Foo { int x; } int foo()(auto ref Foo f = Foo(1)) {} So this should be valid: struct Foo { int x; } int foo()(auto ref f = Foo(1)) {}Side note: Today, issue 7152 is implemented. By that, void foo(in VeryLongNamedStruct x = VeryLongNamedStruct(1)) {} might be shorten to: void foo(in VeryLongNamedStruct x = 1) {}Right. But my use case was a bit more complex, more like: void foo(in VeryLongNamedStruct y = VeryLongNamedStruct(1, 2)) {} I am grateful to Henning Pohl for writing the patch. So do we close down this enhancement request? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 29 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491https://github.com/D-Programming-Language/dmd/pull/2270I think a decision should be taken. What do you think about this issue Henning Pohl? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 30 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX OK, closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 02 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491 PDT ---Can only three people actually take decisions like that? Let me comment on Kenji's four points: 1. True, but these little syntactic improvements make writing D more fun as a whole. 2. This is what D should do more often. 3. The cost of inferring things. If the quality of the error messages are appropriate, it is totally worth it. 4. In which way do "in ref" and "auto ref" conflict with this? Walter has underlined multiple times the importance of beautiful code. And that is the goal of this enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------https://github.com/D-Programming-Language/dmd/pull/2270I think a decision should be taken. What do you think about this issue Henning Pohl?
Jul 02 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491Can only three people actually take decisions like that?I'd like Walter and/or Andrei to give a comment to this (and to your patch). I have asked here, in the main D newsgroup, and your patch was exposed in GitHub for several days.1. True, but these little syntactic improvements make writing D more fun as a whole.Default arguments are not so common...3. The cost of inferring things. If the quality of the error messages are appropriate, it is totally worth it.The point 3 by Hara is probably the most important. If he says this enhancement may cause more typing problems then we should listen to him. At minimum your patch should contain more tests. (But adding tests to a patch is receiving a cold interest risks being a further waste of time.) Thank you for your patch and your comments. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 02 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10491 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 13:17:59 PDT --- While I agree that this would be a nice enhancement, I'm with Kenji in worrying about ever more complex forward reference problems. I don't think it is worth the effort to overcome those problems at the moment, since as Kenji also pointed out, default arguments are not used often. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 09 2013