Bug 9749 – typeof(return) in function signature

This is borderline between enhancement request and bug report. This is sometimes useful when you use nested functions: int main() { typeof(return) foo(typeof(return) y) { return y * y; } return foo(1) + foo(3); } DMD 2.063alpha gives: temp.d(2): Error: typeof(return) must be inside function temp.d(5): Error: function temp.main.foo (_error_) is not callable using argument types (int) temp.d(5): Error: function temp.main.foo (_error_) is not callable using argument types (int) Note that this code gives no errors, so all errors come from "typeof(return) y": int main() { typeof(return) foo(int y) { return y * y; } return foo(1) + foo(3); }

Experimental pull: https://github.com/D-Programming-Language/dmd/pull/1764

Thank you for your patch Andrej. Don, from the GitHub thread: > The enhancement request seems a bit doubtful to me, doesn't it cause confusion? I kind of agree with Don here... Bargaining a little convenience with some potential confusion isn't so good in a programming language. Do you want me to close this ER down?

(In reply to comment #2) > Thank you for your patch Andrej. > > Don, from the GitHub thread: > > > The enhancement request seems a bit doubtful to me, doesn't it cause confusion? > > I kind of agree with Don here... Bargaining a little convenience with some > potential confusion isn't so good in a programming language. > > Do you want me to close this ER down? We could rename it to allow these cases which are currently disallowed: // ok, infer from return type int a(typeof(return) intVar) { return 1; } // ok, infer from return expression auto b(typeof(return) intVar) { return 1; }

(In reply to comment #3) > // ok, infer from return expression > auto b(typeof(return) intVar) > { > return 1; > } Actually that one might be a bit hard to implement. But the other one might be worth doing.

(In reply to comment #4) > But the other one might be worth doing. It's sometimes useful to make the code more DRY. I have renamed this issue.

See the pull request discussion: I doubt that this adds enough value to make up for the amount of confusion it can cause. bearophile, could you maybe name a few use cases where this really helps?

Both of these proposals were rejected.

(In reply to comment #7) > Both of these proposals were rejected. I see. Thank you for all. > But if he can do that for the return type, he can also do it > for the parameter. So the feature doesn't add much of anything. This is not true. Specifying it once instead of twice is more DRY, and this is good.

(In reply to comment #6) > could you maybe name a few use cases where this really helps? It helps to reduce the number of times you have to state a type.