-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
What additional restrictions, if any, should be applied to functions which use positional parameters? #3860
Comments
This comment was marked as spam.
This comment was marked as spam.
Summary of the problem with restriction on Public visibility: Proposed solution: Here are some alternative strategies or patterns that achieve the same goals without imposing such a strict limitation. 1- By encouraging the use of named parameters. |
My stance on this is that we should try out the minimal set of restrictions and see what happens. I feel like we can easily tighten these rules later if useful, and it seems somewhat interesting to leave the flexibility technically in the language. Put differently, I wonder if whether to use this technique in a public API will end up being more of an HOA rule than a building code. |
Leads decision: Per @chandlerc's comment: do not try to proactively add restrictions for where functions with positional parameters can appear (eg, only in non-public interfaces or only in block scopes). |
Summary of issue:
In addition to the proposed restrictions (definition must be attached to the declaration; only one function in an enclosing scope can use positional parameters), an additional restriction was considered. That being, visibility of functions with positional parameters could be restricted to only non-public interfaces. What do the leads think about this candidate additional restriction?
See Lambdas proposal at #3848
Details:
No response
Any other information that you want to share?
No response
The text was updated successfully, but these errors were encountered: