Under my proposal, because the names of the argument become part of the "Real/Mangled" name of the function/method, you would be able to mark the original as deprecated and create the same method/function with new argument names and it would be a 100% backwards compatible API change. So, you would have the best of both worlds.
I think I'll need to give some more details and precision to my proposal for everyone to be able to clearly see what I'm suggesting because I think many of the objections are because I haven't been 100% clear about what I'm proposing.
Hi,
C++ has default arguments. I was under the impression that the consensus was that it’s a failure and no one should ever use it as it makes ABI migrations extremely painful.
I could see call sites using blah(a, b, c, ...) where ... implies Default::default() for further arguments as we have in struct construction. This keeps allows an escape hatch for API compatibility but it would break ABI compatibility since it’s up to the compilation target to generate the values for the default and switching libcool.so.2.1 with libsool.so.2.2 behind the scenes would require a recompilation of the dependent libraries/executables.
Named arguments carry a similar issue. The name becomes part of the API along with the function and types in the argument list. AFAIK, only the types are part of the exported symbol (like C++).
Are ABI migrations even a concern for Rustaceans? I know Cargo doesn’t support using precompiled binaries packages, but with the size of projects growing and the unpleasant compile times of any project depending on tokio and friends, surely it /has/ to support binary packages in the near future for a limited set of targets.
FWIW, that's definitely not the case where I work, probably because we don't have any reason to use dynamic linking so for all the C++ we write we only care about API and not ABI.
