http://d.puremagic.com/issues/show_bug.cgi?id=9238
Jonathan M Davis <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Jonathan M Davis <[email protected]> 2012-12-29 12:08:17 PST --- I'm against the in ref idea. 1. It subverts what in currently does. You _really_ don't want to require that scope be used in this case. Once scope has actually been fixed to actually check for escaping references, you'll either end up with conflicting behavior with in depending on whether it's ref or not, or you'll end up with scope's restrictions on it, which would be horrendously over-restrictive. Not to mention, I'd argue that in is already too overloaded as it is. Too many people use it because they like they idea that it's the opposite of out without taking into account that it means not only const but _scope_. We should _not_ encourage it's use further, let alone give it a conflicting meaning. It's causing enough trouble as it is. 2. I think that that the fact that auto ref allows you to accept both rvalues and lvalues without const is very valuable. Yes, that means that if the function actually mutates the parameter, then lvalue arguments will get mutated whereas the change to rvalue arguments will be lost, but it means that you can get the efficiency benefit without requiring const. And given how restrictive D's const is, lots of people are avoiding it, and there are plenty of legitimate use cases where you _can't_ use it. So, I'd strongly argue for using auto ref such that void foo(auto ref int param); became void foo(ref param); and foo(bar()); gets lowered to something like auto _temp = bar(); foo(bar()); Then if you _don't_ want foo to be able to mutate its argument, you use const void foo(auto ref const int param); and if you don't care, you don't have to. And of course, if you _want_ it to mutate the argument, then you just use plain ref. I am _extremely_ leery of overloading in any further, and we do _not_ want to these types of parameters to have have scope on them. Honestly, if it were up to me, we'd make in on function parameters outright illegal, since I think that overloading it like we already have is confusing and is going to cause a lot of problems once scope is fixed. Let's not make the problem worse. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
