Skip to content

Grammar rule *parameter_modifier* disallows valid V7 constructs #1209

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: draft-v8
Choose a base branch
from

Conversation

RexJaeschke
Copy link
Contributor

[I stumbled on this today while looking at how to spec the addition of scoped to a parameter for a future version.]

The relevant grammar for method parameters in §15.6.2.1 is, as follows:

fixed_parameter
    : attributes? parameter_modifier? type identifier default_argument?
    ;

parameter_modifier
    : parameter_mode_modifier
    | 'this'
    ;

parameter_mode_modifier
    : 'ref'
    | 'out'
    | 'in'
    ;

Rule parameter_modifier allows parameter_mode_modifier or this, but not both. However, two combinations of these are permitted, as follows:

public static class E
{
    public static void F1b(this in int p) { }
    public static void F1d(this ref int p) { }
}

This possibility is supported by the text in §15.6.10 Extension methods, which states:

When the first parameter of a method includes the this modifier, that method is said to be an extension method. Extension methods shall only be declared in non-generic, non-nested static classes. The first parameter of an extension method is restricted, as follows:

  • It may only be an input parameter if it has a value type
  • It may only be a reference parameter if it has a value type or has a generic type constrained to struct
  • It shall not be a pointer type.

I propose the following grammar change:

parameter_modifier
    : parameter_mode_modifier
    | 'this' parameter_mode_modifier?
    ;

Now this new grammar also allows this out, which according to my compiler is not permitted [CS8328], and that suggests we also add to the extension bullet list above, the following constraint:

  • It shall not be an output parameter.

@RexJaeschke RexJaeschke added meeting: discuss This issue should be discussed at the next TC49-TG2 meeting meeting: proposal There is an informal proposal in the issue, worth discussing in a meeting labels Nov 17, 2024
@RexJaeschke RexJaeschke added this to the Pre-C# 8.0 milestone Nov 17, 2024
@RexJaeschke RexJaeschke requested a review from jnm2 November 17, 2024 17:17
@RexJaeschke
Copy link
Contributor Author

Re my second suggestion, I just found the following in §15.6.2.1:

If the parameter is a struct type or a type parameter constrained to a struct, the this modifier may be combined with either the ref or in modifier, but not the out modifier. Extension methods are further described in §15.6.10.

That said, having the new bullet I proposed clarifies it at the parameter end of the call in the case of extension methods, which are not singled out by the above quote.

Copy link
Contributor

@Nigel-Ecma Nigel-Ecma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requires a change to the grammar, apart from that the changes are good.

In the preexisting text I did notice that a reference parameter can be of a generic type constrained to a struct, an input parameter cannot be, and there appears to be no explanation why. The answer can be found in the Readonly references proposal, should something (normative or informative) be added?

Copy link
Contributor

@jskeet jskeet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rename parameter_modifier to parameter_modifiers? It doesn't feel like this ref is a single parameter modifier. This is purely a stylistic thing, and I'm happy to be overruled.

@Nigel-Ecma
Copy link
Contributor

Can we rename parameter_modifier to parameter_modifiers? It doesn't feel like this ref is a single parameter modifier. This is purely a stylistic thing, and I'm happy to be overruled.

I'll vote against on this one – not because I think the current naming in this area is good, it isn’t really, but because making it plural won’t make it any better so stick with the status quo.

@jskeet jskeet modified the milestones: Pre-C# 8.0, C# 8.0 Nov 20, 2024
Copy link
Contributor

@jskeet jskeet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Like Nigel, I'm basically happy with this, but I agree with the ordering flexibility.)

Copy link
Member

@BillWagner BillWagner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, basically happy as well.

@jskeet
Copy link
Contributor

jskeet commented Feb 18, 2025

Note for the February meeting: this PR has not changed (as far as I can see) since November.

@jskeet jskeet closed this Feb 18, 2025
@jskeet jskeet reopened this Feb 18, 2025
@jskeet
Copy link
Contributor

jskeet commented Feb 18, 2025

(Closure was accidental.)

@jskeet jskeet removed meeting: discuss This issue should be discussed at the next TC49-TG2 meeting meeting: proposal There is an informal proposal in the issue, worth discussing in a meeting labels Apr 16, 2025
@RexJaeschke
Copy link
Contributor Author

closed/reopened to run all checks

@RexJaeschke RexJaeschke reopened this May 29, 2025
Co-authored-by: Nigel-Ecma <6654683+Nigel-Ecma@users.noreply.github.com>
@RexJaeschke
Copy link
Contributor Author

@Nigel-Ecma I made no change re your suggestion in #1209 (review). Feel free to add a note in a separate PR.

@RexJaeschke RexJaeschke requested a review from Nigel-Ecma May 29, 2025 21:12
@RexJaeschke RexJaeschke reopened this Jun 23, 2025
@RexJaeschke RexJaeschke added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Jun 23, 2025
Copy link
Contributor

@Nigel-Ecma Nigel-Ecma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spun off #1361 following Rex’s comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meeting: discuss This issue should be discussed at the next TC49-TG2 meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy