luau-lang/rfcs
1
0
Fork 0
mirror of https://github.com/luau-lang/rfcs.git synced 2025-05-04 10:43:48 +01:00
Code Issues Projects Releases Packages Wiki Activity

Add reason for allowing nil parameter

Browse source
This commit is contained in:
Aviral Goel 2024-04-17 11:00:05 -07:00
parent 8a93c8e4c9
commit 8351e99941
1 changed files with 3 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
docs/syntax-attributes-functions-parameters.md
View file

@ -17,7 +17,9 @@ attribute = '@' NAME
| '@' NAME '(' ATOMIC-LITERAL (',' ATOMIC-LITERAL)* ')'
```
The only extension proposed to the [Attributes](./syntax-attributes-functions.md) RFC is in the second line which allows one or more comma-separated literals to be supplied to the attribute. The `ATOMIC-LITERAL` category includes values of type `boolean`, `number`, `string`, and the `nil` value. There are three notable exclusions in this syntax.
The only extension proposed to the [Attributes](./syntax-attributes-functions.md) RFC is in the second line which allows one or more comma-separated literals to be supplied to the attribute. The `ATOMIC-LITERAL` category includes values of type `boolean`, `number`, `string`, and the `nil` value. The `nil` value can be be used for "optional" parameters when no valid value exists. As a hypothetical example, consider the `@deprecated(<new-function-name>, <warning-message>)` attribute. Assume a function is being marked deprecated because we are getting rid of the feature entirely and there is no other function replacing it. In that case, we can pass `nil` for the `<new-function-name>` parameter. An alternative would be to allow this attribute to have either one or two parameters. But that still won't help when an attribute can take three parameters and we want to ignore the second.
There are three notable exclusions in this syntax.
1. Literal `table` values are excluded from being passed as parameters since they are composite structures; information supplied via table fields can be passed as separate parameters to the attribute. If they are still deemed useful, a follow-up RFC can introduce them with motivating use cases.
2. Attributes with empty parameter lists are disallowed. It can be argued that this leads to syntactic irregularity, but attributes with empty parameter lists convey no useful information over parameterless attributes, and have no compelling use case. Furthermore, they might complicate attribute processing in the implementation which will have to check for both `@NAME` and `@NAME()` forms and treat them equally.