Skip to content
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

Closed
bombless opened this issue Feb 13, 2015 · 4 comments
Closed

Reject argument name in function signature for inconsistency #838

bombless opened this issue Feb 13, 2015 · 4 comments

Comments

@bombless
Copy link

Function signature is not even documented in the reference.
For a function signature

type T = fn(arg1: c_void, c_void);

the argument names can be ignored, and there's two drawbacks here:

  • Fn/ FnOnce/ FnMut traits don't have argument names, so it leads to inconsistency
  • it's harder to parse if argument names are optional, for syntax-highlighting and other purposes

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

@brendanzab
Copy link
Member

I'm not sure I agree - the argument names are very useful for documentation purposes.

@bombless
Copy link
Author

@bjz

useful for documentation purposes

But it's just signature. Different functions can have same signature with totally different meanings.
So maybe some time you add an argument name by means of self-documentation, then you use the second function with same signature, former argument name may become nonsense.

So the type of the argument is all it is about, an optional name here can even be harmful for documentation.

@Diggsey
Copy link
Contributor

Diggsey commented Feb 14, 2015

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.

@bombless
Copy link
Author

bombless commented Mar 7, 2015

I just realized that signatures in traits also have optional argument names, so this may not be a good idea.

@bombless bombless closed this as completed Mar 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants