carbon-lang icon indicating copy to clipboard operation
carbon-lang copied to clipboard

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

Open CJ-Johnson opened this issue 10 months ago • 3 comments

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 https://github.com/carbon-language/carbon-lang/pull/3848

Details:

No response

Any other information that you want to share?

No response

CJ-Johnson avatar Apr 04 '24 18:04 CJ-Johnson

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

justzh avatar Apr 05 '24 15:04 justzh

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

Hira-Iftikhar-123 avatar Apr 14 '24 16:04 Hira-Iftikhar-123

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.

chandlerc avatar May 16 '24 08:05 chandlerc

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

zygoloid avatar May 28 '24 22:05 zygoloid