www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10491] New: Type inference for function arguments with default value

reply d-bugmail puremagic.com writes:
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


--- Comment #0 from bearophile_hugs eml.cc 2013-06-27 18:05:52 PDT ---
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
next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #1 from Henning Pohl <henning 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: -------
Jun 28 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10491



--- Comment #2 from Kenji Hara <k.hara.pg 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: -------
Jun 28 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10491



--- Comment #3 from bearophile_hugs 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: -------
Jun 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10491



--- Comment #4 from bearophile_hugs 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: -------
Jun 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10491


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #5 from bearophile_hugs 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: -------
Jul 02 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10491



--- Comment #6 from Henning Pohl <henning 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: -------
Jul 02 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10491



--- Comment #7 from bearophile_hugs 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: -------
Jul 02 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10491


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com


--- Comment #8 from Walter Bright <bugzilla 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: -------
Jul 09 2013