Bug 14742 – Changing function signatures breaks code

This issue is a follow-up to my GitHub comment: https://github.com/D-Programming-Language/phobos/pull/3422#issuecomment-115654816 Reposting it here so it doesn't get lost: """ OK, so this actually broke code for me. I have a wrapper that wraps arbitrary file operation functions and makes them atomic (by writing to a temporary file and renaming it onto the target). I use ParameterTypeTuple to find which parameter contains the "target path" string, which doesn't work now that the function is a template. I also had a similar breakage when std.file.copy gained a third optional parameter. Since the usual way to create a function wrapper (using ParameterTypeTuple) does not account for optional parameters, the parameter became non-optional in the wrapped function, which broke code using it. It seems to me that to truly avoid all breaking changes, we can't touch any Phobos function signatures at all. This is probably too drastic, so I think we need to establish some conventions of what breaking changes are acceptable. """

> It seems to me that to truly avoid all breaking changes, we can't touch any Phobos function signatures at all. This is probably too drastic, so I think we need to establish some conventions of what breaking changes are acceptable. Please keep in mind that deprecation is *not* breakage in situations that allow redundancy, like renames and overloads. We just need to ensure that the user understands why there is more than one (documentation comment), and which one is preferred (`deprecated` attribute). There is a raging tug-of-war between those who want progress and evolution, and those who want stability. IMO, the best way forward, and an appropriate compromise, is deprecation without removal. As an example, the .Net Framework has had deprecated features since v2.0 (10 years ago), but they are still available for use, and likely will be in the far future (https://msdn.microsoft.com/en-us/library/hh419162%28v=vs.110%29.aspx).

How were you looking for the "target path" string? In any case, a rule that functions cannot become template functions would be extremely limiting. One way to avoid adding optional parameter breakage is to add an overload instead. But I suspect that would then break introspection code that is not expecting an overload.

(In reply to Walter Bright from comment #2) > How were you looking for the "target path" string? ParameterIdentifierTuple > In any case, a rule that functions cannot become template functions would be > extremely limiting. > > One way to avoid adding optional parameter breakage is to add an overload > instead. But I suspect that would then break introspection code that is not > expecting an overload. I just tried this program: ``` void f(int i) {} void f(string s) {} pragma(msg, ParameterTypeTuple!f); ``` It prints (int). I'm not sure if this is a behavior we would want to rely on, though.

(In reply to Vladimir Panteleev from comment #3) > It prints (int). I'm not sure if this is a behavior we would want to rely > on, though. It's clearly just picking the first one. I'd prefer it gave a compiler error for overloads.

I'm going to resolve this as wontfix. I know I come down hard on breaking changes, but in my mind I thought it was good enough if calling the function with the same arguments continues to work. For example, adding a parameter with a default value will enable the calls to work, but of course anything using ParameterTypeTupe or relying on the particular mangled name is going to break. I'm going to say that the latter two cases are a little too restrictive to say we won't break them.