Changeset 1f11818 for doc/proposals/named-parameters.md
- Timestamp:
- Jul 31, 2024, 10:28:50 AM (3 months ago)
- Branches:
- master
- Children:
- 3a7cd15
- Parents:
- 9476549
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/proposals/named-parameters.md
r9476549 r1f11818 17 17 + Ada - Named Association 18 18 + C - Designators (limited) 19 20 Status of Proposal 21 ------------------ 22 This proposal is "an examination", there are still issues to solve. Including 23 syntax, the exact rules of how forward declarations and definitions must 24 relate. It does break through a major problem C had, in that names of 25 parameters are not consistent. By using C parameters as positional-only 26 parameters so that does not cause issues. 19 27 20 28 Overview of New Features … … 69 77 considered, but most can cleanly be removed. 70 78 79 Note that matching arguments to parameters is tied up into matching calls 80 with definitions, and requires arguments to be resolved, and so has to happen 81 within the resolver. 82 71 83 First, the positional parameters have to be sorted out. 72 84 … … 125 137 generalized to function calls (not even initializers we resolve as functions) 126 138 because of overloading. 139 140 Syntax Options 141 -------------- 142 The syntax suggested above both does not work and may be incomplete. It was 143 good enough for the initial descussion but will need some further work. 144 145 The issue with the above syntax is that `TYPE .NAME` can look like a 146 qualified type to the parser. Considering how wide spreak the qualified type 147 syntax is, it could be changed. Here are some syntax suggestions: 148 149 Named Argument: `.NAME = EXPR` 150 Named (Required) Parameter: `TYPE .NAME` 151 Named (Optional) Parameter: `TYPE .NAME = EXPR` 152 153 The first suggestion is an attempt to use C designator syntax as the name 154 syntax. A named parameter is now a generialization of designators. The 155 parameters are added into a function's parameter list. 156 157 `@NAME = EXPR` | `TYPE @NAME` | `TYPE @NAME = EXPR` 158 `?NAME = EXPR` | `TYPE ?NAME` | `TYPE ?NAME = EXPR` 159 160 Some other characters that could be used in the same syntax. The `@` symbol 161 hints at some location/address. Peter was just excited about `?` but it is an 162 little used symbol and parses at this time. This does weaken the connection 163 with designators, which was the main advantage of the designator like syntax. 164 165 Named Argument: `NAME: EXPR` 166 Named Parameter: `NAME: TYPE NAME0` | `TYPE NAME:` 167 168 Another bit of C syntax we could try to adapt to named parameters are labels. 169 We reuse the label syntax used at the statement level at the expression level 170 to note where (with which parameter) this expression goes. 171 172 This syntax (the first option for the named parameter) is also has an example 173 of a possible (but not popular) feature where the parameter name (the 174 identifier used inside the function) and the parameter label (the identifier 175 used at the call site) are independent. 176 177 `PARAMS;PARAMS` | `;PARAMS` 178 179 Another way to describe the type of parameters is by dividing the parameter 180 list into sections. Here we replace a `,` separator between two parameters, 181 with a single (per parameter list) `;` that marks the end of the positional 182 parameters. The argument syntax would have to be borrowed from some other 183 example (such as the designator one, where the parameter is the problematic 184 one for the parser), possibly with another `;` separator to add context. 185 Also, the `;` separator can appear at the beginning of the parameter list as 186 well if all parameters are positional. 187 188 Named Argument: `NAME @= EXPR` 189 Named Parameter: `TYPE NAME @= EXPR` 190 191 Another syntax to modify is assignment, with a special "assign to parameter" 192 operator (although structurally it 193 194 `NAME := EXPR` | `TYPE NAME := EXPR` 195 196 Like with the variations of the designator-like syntax, the separator could 197 be changed out, so that symbol can be used as the identifying feature of the 198 named argument. 199 200 The incompleteness is that most of these just have one more parameter 201 declaration. That is, there is only syntax for positional-or-named parameters 202 or named-only parameters, so far it has been named-only. Positional-only 203 parameters are "locked" to the C syntax for compatability reasons. Supporting 204 both cases gives additional flexibility and could be done by combining two 205 of the above syntax (or by altering one). 206 207 void call(int position, char .position_or_name = a; double .name = b); 208 209 Note, that C-style autogenerated constructors would still be positional or 210 named parameters for compatability. 127 211 128 212 Run-time Implementation
Note: See TracChangeset
for help on using the changeset viewer.