Repository navigation
[Version 9.0] Feature support for top level statements - #1454
Conversation
d872f61 to
07946a2
Compare
|
@BillWagner There is one grammar change: the extension of compilation_unit to allow |
BillWagner
changed the title
b9bed76 to
197acef
Compare
197acef to
ade6460
Compare
ade6460 to
db48965
Compare
|
An earlier version of this feature is already present on |
jskeet
added
the
meeting: discuss
|
Applied "meeting: discuss" so that we can all perform a first round of review before the next meeting. |
Add support for top-level statements Add support for top-level statements fix md formatting tweak generated entry-point signature table Update basic-concepts.md Add mention of attribute System.Runtime.CompilerServices.CallerMemberName mention invoking method in top-level statement situation fix link
db48965 to
a425ffb
Compare
- With adding task-valued entry points and now top-level statements some re-org was indicated – the result is shorter, but opinions may vary on the structure… - Some stuff was removed as being tied to a specific implementation - Startup and termination are combined under one clause and the process is described as a series of steps which handles both `void`, `int` and `Task` typed entry points. - With the intro of top-level statements an entry point may no longer be named `Main` – this results in little changes across the Standard where `Main` was referenced as the entry point. - For the external mechanism there was a possible discrepancy, depending on how you read it, between the Standard wording “an external mechanism may be used to specify which method” and a certain compiler which takes a “/main:type” option – note there former states method and the later type. The description has been re-written to allow a type (implying `Main`) or method (regardless of name) to be specified. This covers a certain compiler and allows others to specify a method if they so choose. - “execution environment” vs. “host environment” – I think the former tends to be read as the language runtime support (which may include a VM) and the latter as the OS GUI or CLI environment. Neither are defined, the latter is used just 3 times. This has not been changed, but should it be? - “entry point” has been hyphenated when used as a compound modifier for a noun, e.g. “entry-point method”. English grammarians can decide if that is correct and I used the correct one in each place… - The initial proposed grammar changes for top-level statements have been fixed, this also required changes to the text. - A grammar test is included.
|
|
||
| ### §entry-point-invocation Entry point invocation | ||
|
|
||
| If the entry point declares a parameter, then the implementation shall as the initial value of that parameter provide a non-null reference to a string array. This array shall consist of non-null references to zero or more strings, called ***application parameter***s, which are given implementation-defined values by the host environment prior to application startup. |
There was a problem hiding this comment.
Should we rename these to "application arguments"? That would be more consistent with parameter/argument elsewhere? (I only noticed due to the note below.)
There was a problem hiding this comment.
A caller passes arguments, the callee has parameters. So the CLI passes application arguments, the entry-point gets application parameters. I just did a quick check and the C Standard has the names them this way as well. So I think application parameters is correct here. Maybe the Note could be written better?
There was a problem hiding this comment.
Unresolving so we can discuss it in the meeting. I completely agree with the general argument/parameter distinction, but leaving aside the array-ness:
- I tend to think of the parameters as the variables themselves, whereas the arguments are the values stored in those parameters. Here we're talking about the values provided by the CLI (the strings themselves) so they still feel more like arguments than parameters to me. If I run "myapp x y z" then the strings "x", "y" and "z" are the arguments, right? You could reasonably say that
args[0],args[1]andargs[2]are the parameters... - It still ends up being a bit odd with the note
No need to spend a long time on this - if others are okay calling these parameters, it's not a hill I want to even get a grazed knee on, but let's talk about it very briefly.
|
Other than the noted oddity, we think this is ready for "final tweaks and final review". |
This change describes how a top-level declaration in a generated method body can hide global items if referenced by simple_name from elsewhere in the compilation_unit, i.e. “de-scopes” them. No rationale is provided, not the Standard’s job, but some might say C# really needs one… maybe an annotated Standard?
|
P.S. @BillWagner – I can’t request a review from you, I guess as you are the “author”, but I’m sure you’ll know how to get around that! |
|
Will review on Monday. |
jskeet
left a comment
jskeet
left a comment
There was a problem hiding this comment.
I think we'll want to talk about this a little more, but I'm hopeful we can merge it during the meeting.
4 participants
This PR contains the work for Top-level statements in C# 9.
The commits from #980 were squashed to the first commit on this branch.
The ANTLR grammar is failing. I admit I'm not sure why. There are no grammar changes in this PR.