On Sunday, January 27, 2013 01:32:07 Namespace wrote: > > If we add a feature as a temporary measure and then remove it > > later, we're > > likely to end up breaking code when it's removed. > > No, as far as I can see this don't happend. auto ref works > currently very well for template functions and the pull I suggest > adds the same functionality for normal functions. > So if one day an official solution is there, nothing will be > broken. The solutions code has (maybe) another implementation but > it don't touch auto ref functionality in general.
But it may not even end up being the case that using auto ref on non-templated functions is the solution. It may end up being something else entirely. Ignoring @safety issues, it seems to me like it would be the most straightforward solution, but there are @safety issues with ref in general that need to be addressed, and Andrei intends to address them as part of whatever happens with auto ref. That mean that auto ref gets used for non- templated functions, or it could mean something very different. I don't know what exactly the solution that Andrei is working on could entail. For all I know, it'll involve letting ref in general accept rvalues (much as I tihnk that that's a horrible idea, it _has_ been suggested before). So, without a clear idea of what we're going to want to do, merging in the pull request which makes auto ref work for non-templated functions is a bad idea. It could ultimately end up being fine, or it could end up breaking more code when the real solution gets implemented. - Jonathan M Davis
