Changeset 1f11818


Ignore:
Timestamp:
Jul 31, 2024, 10:28:50 AM (3 months ago)
Author:
Andrew Beach <ajbeach@…>
Branches:
master
Children:
3a7cd15
Parents:
9476549
Message:

Updated the named parameter proposal. Adding sections (or paragraphs) for syntax options, the current status and where it is placed in compilation.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/named-parameters.md

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