-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reject argument name in function signature for inconsistency #838
Comments
I'm not sure I agree - the argument names are very useful for documentation purposes. |
But it's just signature. Different functions can have same signature with totally different meanings. So the type of the argument is all it is about, an optional name here can even be harmful for documentation. |
I don't agree either - a common case is that you alias the function signature for a specific purpose (for example a callback) the argument names are then incredibly useful as documentation, for both for someone implementing the callback and for someone invoking the callback. The alias contains more information than just the signature, it also corresponds to one specific use for that signature, even if there's no way for the type system to enforce that. |
I just realized that signatures in traits also have optional argument names, so this may not be a good idea. |
Function signature is not even documented in the reference.
For a function signature
the argument names can be ignored, and there's two drawbacks here:
And the syntax of extern functions should be changed accordingly for obvious reason.
So this will break current code, thus need to be landed before 1.0, or even before beta.
cc @nikomatsakis @AngryLawyer @mvdnes
The text was updated successfully, but these errors were encountered: