What additional restrictions, if any, should be applied to functions which use positional parameters?

[CJ-Johnson]

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

[Hira-Iftikhar-123]

Summary of the problem with restriction on Public visibility:
this is beneficial as the restriction could help enforce good design practices, encouraging developers to use more explicit and self-documenting parameter passing methods, such as named parameters or data structures

Proposed solution:
The solution is to provide clear guidance and examples which could help developers to understand the reason of restriction and they can therefore, adhere the best practices of parameter passing.

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.
2- By promoting the use of data structures.
3- By providing clear guidelines and examples.
4- By considering gradual adoption.(by gradually applying restrictions.)

[chandlerc]

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.