What additional restrictions, if any, should be applied to functions which use positional parameters? about carbon-lang HOT 3 OPEN

See my other response for this. You need to write a trifactorial function inverse in order to close this issue.

from carbon-lang.

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.)

from carbon-lang.

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.

from carbon-lang.