[Issue 10491] Type inference for function arguments with default value
https://issues.dlang.org/show_bug.cgi?id=10491 RazvanN changed: What|Removed |Added CC||d...@me.com --- Comment #9 from RazvanN --- *** Issue 17186 has been marked as a duplicate of this issue. *** --
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2013-07-09 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: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #5 from bearophile_h...@eml.cc 2013-07-02 00:29:40 PDT --- OK, closed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491 --- Comment #6 from Henning Pohl henn...@still-hidden.de 2013-07-02 13:04:46 PDT --- (In reply to comment #4) (In reply to comment #1) https://github.com/D-Programming-Language/dmd/pull/2270 I think a decision should be taken. What do you think about this issue Henning Pohl? 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: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491 --- Comment #7 from bearophile_h...@eml.cc 2013-07-02 14:00:23 PDT --- (In reply to comment #6) Can 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: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491 --- Comment #4 from bearophile_h...@eml.cc 2013-06-30 17:07:20 PDT --- (In reply to comment #1) https://github.com/D-Programming-Language/dmd/pull/2270 I 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: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491
--- Comment #3 from bearophile_h...@eml.cc 2013-06-29 01:24:25 PDT ---
(In reply to comment #2)
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: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Keywords||pull CC||henn...@still-hidden.de --- Comment #1 from Henning Pohl henn...@still-hidden.de 2013-06-28 09:52:10 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: ---
[Issue 10491] Type inference for function arguments with default value
http://d.puremagic.com/issues/show_bug.cgi?id=10491
--- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-06-28 21:13:50 PDT ---
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: ---
