Skip to content
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

Add rules for ref safety #742

Merged
merged 27 commits into from
May 19, 2023
Merged

Conversation

BillWagner
Copy link
Member

This updates the Variables clause with several sections for ref safety.

This PR is primarily from taking the text from the Span safety proposal and editing into the style for the standard.

In addition, a few rules were added:

  1. out parameters can't be returned by ref
  2. An instance method of a struct can't return this by ref.
  3. An in parameter can't be returned by ref, only by ref readonly.

The third rules makes this illegal:

public ref int MakeWritable(in int p)
{
    return ref p; // Error,
 }

readonly int j = 5;

ref int k = MakeWritable(in j);
k = 7;

- A local of `ref struct` type and uninitialized at the point of declaration is *safe-to-return* from the entire enclosing method. Its *safe-to-escape-scope* is the calling method.
- Otherwise the variable's type is a `ref struct` type, and the variable's declaration requires an initializer. The variable's *safe-to-escape-scope* is the same as the *safe-to-escape* of its initializer.

### §ref-span-safety-parameters Parameter escape scope
Copy link
Member Author

Choose a reason for hiding this comment

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

This section doesn't handle a rule needed later in C# 11 (when ref fields are allowed):

  • A ref parameter can't be returned by ref as a field in another ref argument.

For example:

ref struct S { 
  ref int refField;
}

void M(ref S p1, ref int p2) {
   p1.refField = ref p2;
}

These rules would allow that because both p1 and p2 have ref-safe-to-escape-scope of calling-method. But, doing so could be dangerous: p2 could be a local in the calling method, and p1 could be a static field in the type of the calling method.

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.

This is a very shallow review - I'll do a more complete one when I have more mental energy. (I get very confused by all of this.)

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
@BillWagner BillWagner added the meeting: discuss This issue should be discussed at the next TC49-TG2 meeting label Feb 23, 2023
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
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.

I haven't done a thorough review today but did find a possible typo and, to me at least, a lack of distinction between a variable/location and it’s contents. I know this stuff can be hard to comprehend for many (a student) – variables have names & values, and a name can itself be a value (aka reference, pointer, address – words which may have different semantics depending on the language). We just need to be clear what is escaping etc. using whatever language we decide or it will be confusing to many.

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
@BillWagner BillWagner marked this pull request as ready for review March 22, 2023 18:32
@BillWagner
Copy link
Member Author

@jskeet I think this one is now ready. I'd like to have async reviews before our April meeting. If so, I can clean up the remaining ref related PRs for V7.

@jskeet
Copy link
Contributor

jskeet commented Mar 22, 2023

Sounds good to me. We can discuss it in today's meeting to try to get anything sync out of the way.

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.

A bunch of comments that I hope are useful. The whole thing bamboozles me anyway, but I think it's also harder to read because a name change may have been incompletely implemented. (Either that, or we need to define safe-to-escape-scope somewhere...)

I'm hoping that next time I look, it'll make more sense to me :) (I know the gist of what we're trying to achieve, but the terminology somehow just won't stick in my brain.)

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
Copy link
Member Author

@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.

responding to initial review

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
@jskeet
Copy link
Contributor

jskeet commented Mar 27, 2023

Just as an FYI: I'll look at this again tomorrow UK time, and answer questions then.

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.

I think I'm getting closer to approving :) At some point I think we'll need to just say "Good enough for now" and make any further changes later.

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
Copy link
Member Author

@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.

First update to resolve many of the review comments.

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
Copy link
Member Author

@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.

Tagging @jaredpar @gafter @cston @RikkiGibson to look at the diffs for #d8dd5d4523dc88c51ad2dc7888968bb5659ad0de

From an earlier conversation, I'm splitting the rules for ref_safe_to_escape (not referred to as ref_safe_scope, and safe_to_escape.

The reason is that the safe_to_escape rules are only interesting in how they apply to ref struct types. Any other variable type can be copied (by value) anywhere.

A ref struct is constrained: It can only be copied within the ref_safe_scope of its referent. Moving these rules into the section on ref structs makes that distinction more clear.

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
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.

Just a single comment but git decided it needed to be a review…

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
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.

Much clearer than before, thanks. I've raised various comments, but I think my overall feeling is:

  • We need another pass at consistency of terms and dash-separation vs underscore_separation
  • It feels like we're missing a definition of "safe to ref return". It's possible I just missed it though!

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
@BillWagner BillWagner added this to the C# 7.x milestone Apr 19, 2023
@gafter gafter self-requested a review April 19, 2023 20:27
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.

@gafter will have a look at this, and there are a few actions defined in comments, but otherwise, we're ready to merge.

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
@RexJaeschke
Copy link
Contributor

RexJaeschke commented Apr 26, 2023

@ BillWagner. Per your request, I just looked over this PR and saw a potential problem in the following:

There are three valid ref-safe-scopes:

  • block: A variable_reference to a local variable declared in a block is valid from its declaration to the end of the block in which it is declared. The ref-safe-scope of a local variable is block. A local variable declared in a method has a ref-safe-scope of the block that defines the method. A variable declared in a block is a valid referent only if the reference variable is declared in the same block after the referent, or a nested block.
  • function-member: A variable_reference to a value parameter on a function member declaration, including the implicit this parameter is valid in the entire function member. The ref-safe-scope of the fields of a struct type is function-member. A variable with ref-safe-scope of function-member is a valid referent only if the reference variable is declared in the same function member.
  • caller-scope: Member fields of a class type and ref parameters have ref-safe-scope of caller-scope. A variable with ref-safe-scope of caller-scope can be the referent of a reference return. A variable that can be the referent of a reference-return is safe-to-ref-return.

I'm concerned about defining a new term called block, as we already have a grammar rule by that name. My first thought was to rename your 3 new terms ref-safe-block-scope, ref-safe-function-member-scope, and ref-safe-caller-scope. However, I realize they are rather long, and perhaps a little unwieldy. But it does directly relate them.

In the definition of block, "The ref-safe-scope of a local variable is block.", if "block" is intended to be a reference to a grammar rule, it should be italicized. Likewise for "function-member" in "The ref-safe-scope of the fields of a struct type is function-member." in the function-member definition EXCEPT that grammar rules use "_" rather than "-", so I'm not sure what this (and possibly "block") are referring to.

@BillWagner
Copy link
Member Author

I'm concerned about defining a new term called block, as we already have a grammar rule by that name. My first thought was to rename your 3 new terms ref-safe-block-scope, ref-safe-function-member-scope, and ref-safe-caller-scope. However, I realize they are rather long, and perhaps a little unwieldy. But it does directly relate them.

I'll propose that we should use these terms. Yes, they are unwieldy, but so are the concepts. These terms directly relate to the concepts, as you say.

I've been looking for terms that were both succinct and descriptive, and I've always come up short. I think descriptive wins.

I'd like others thoughts before I make those edits. Tagging @gafter @jskeet @MadsTorgersen @Nigel-Ecma

@Nigel-Ecma
Copy link
Contributor

I'll propose that we should use these terms. Yes, they are unwieldy, but so are the concepts. These terms directly relate to the concepts, as you say.

I've been looking for terms that were both succinct and descriptive, and I've always come up short. I think descriptive wins.

I'd like others thoughts before I make those edits. Tagging @gafter @jskeet @MadsTorgersen @Nigel-Ecma

Agree, go wth the longer descriptive terms

BillWagner and others added 5 commits May 8, 2023 10:37
Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>
This include comments, and fixing the formatting after consulting with Rex.
These belong in the PR for ref structs, and in the section on ref structs.
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.

Minor comments, but I think I'm still fine with it. There may well be nuances that I've missed - the whole thing is quite confusing, but that's just the nature of it.

standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Show resolved Hide resolved
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.

Minor comments, but I think I'm still fine with it. There may well be nuances that I've missed - the whole thing is quite confusing, but that's just the nature of it.

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.

Minor comments, but I think I'm still fine with it. There may well be nuances that I've missed - the whole thing is quite confusing, but that's just the nature of it.

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.

Minor comments, but I think I'm still fine with it. There may well be nuances that I've missed - the whole thing is quite confusing, but that's just the nature of it.

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.

I'm marking this a "request changes" but I'm only suggesting the change and others might manage better wordsmithing.

standard/variables.md Outdated Show resolved Hide resolved
BillWagner and others added 2 commits May 15, 2023 11:15
Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>
This needs to be added to dotnet#213 once this PR is merged.
standard/variables.md Outdated Show resolved Hide resolved
@BillWagner BillWagner mentioned this pull request May 17, 2023
standard/variables.md Outdated Show resolved Hide resolved
standard/variables.md Outdated Show resolved Hide resolved
Updates from the 5/17 meeting.
@BillWagner BillWagner changed the base branch from draft-v7 to v7-ref-features May 19, 2023 15:46
@BillWagner BillWagner merged commit 65d1c53 into dotnet:v7-ref-features May 19, 2023
@BillWagner BillWagner deleted the ref-span-safety branch May 19, 2023 18:16
BillWagner added a commit that referenced this pull request Jun 7, 2023
* Add rules for `ref` safety (#742)

* first pass at safety rules

This mostly incorporates the feature spec language.

* Add rule for `out` parameters

Out parameters have a ref safe to escape scope of the current method, not the calling method.

* Add readonly rule.

* fix headers

no code fences in headers

* Apply suggestions from code review

Co-authored-by: Jon Skeet <skeet@pobox.com>

* updates from reviews

Updates from code review

* style fix

* respond to feedback

Ref like fields do have storage, but that storage may refer to a variable that is a struct parameter or varialbe.

* respond to feedback

Respond to existing feedback.

* Introduce definitions

Introduce better definitions for the "lifetime" of reference variables. I avoided the term "lifetime' because of its runtime connotation. Instead, I used the "scope" where a "variable declaration" is valid.

From there, next define the safe scopes and the ref safe scopes for different variable classifications.

Finally, I shortened the terms *safe-to-escape-scope* and *ref-safe-to-escape-scope* to "*safe-scope* and *ref-safe-scope*. The text doesn't make it clear why the "escape" term is used, and it doesn't seem to add clarity.

* add examples

* respond to feedback.

* Apply suggestions from code review

Co-authored-by: Jon Skeet <skeet@pobox.com>

* address review comments

This addresses most of the comments in the most recent reviews.

The next commit will make an attempt to use a single term for *ref_safe_scope*.

* Remove *safe_scope* rules

Once I push these, I'll add notes about which rules must be added to #601

* Update standard/variables.md

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* Update standard/variables.md

* Respond to review comments.

* Feedback from April meeting

This include comments, and fixing the formatting after consulting with Rex.

* remove ref struct descriptions

These belong in the PR for ref structs, and in the section on ref structs.

* Apply suggestions from code review

Co-authored-by: Jon Skeet <skeet@pobox.com>

* respond to feedback.

* Apply suggestions from code review

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* remove missing xref

This needs to be added to #213 once this PR is merged.

* Updates from 5/17 meeting.

Updates from the 5/17 meeting.

* fix build warning

---------

Co-authored-by: Jon Skeet <skeet@pobox.com>
Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* C# 7.x: ref struct (#601)

* Split out `ref struct` from #33.

* Add ref safety rules as they apply to ref structs

Declare that `ref structs` have a *ref_safe_scope* that matches their initializing expressions. Restrict copying of a `ref struct` (by value) to its *ref_safe_scope*. Then, define what the *ref_safe_scope* is depending on the initializing expression.

* forgot to finish one sentence.

* Add note on iterators and async methods

The previous normative language was

* respond to review feedback.

* Respond to meeting feedback, part 1

Respond to all meeting feedback *except* updating the rules on *safe_to_escape*.

That's coming in the next commit.

* incorporate safe rules.

Pull all safety rules related to safe-scope from PR on ref variables
into the section on ref structs.

* respond to feedback.

* Apply suggestions from code review

Co-authored-by: Jon Skeet <jonskeet@google.com>

* respond to feedback.

* Apply suggestions from code review

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* respond to feedback.

* Update per 5/17 committee meeting.

* update definition

* found one more comment to address

---------

Co-authored-by: Neal Gafter <nmgafter@fb.com>
Co-authored-by: Bill Wagner <wiwagn@microsoft.com>
Co-authored-by: Jon Skeet <jonskeet@google.com>
Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* C# 7.x: ref locals and returns (#213)

* Update expressions.md

* Update statements.md

* Update classes.md

* Update delegates.md

* Relocate ('ref' 'readonly'?)? to local_variable_declaration

I had this grammar extension in the wrong place

* Add support for ref readonly iteration variables to foreach

* Minor tweak to v7 spec for ? ref : ref

* build fixes

* fix merge error

* one more build issue

* light editing

* fix section references

* fix link errors

* edit to address feedback, link to ref safety rules.

* fix markdown lint error

* Apply suggestions from code review

Co-authored-by: Jon Skeet <jonskeet@google.com>

* respond to feedback

* respond to feedback.

* Apply suggestions from code review

Co-authored-by: Jon Skeet <jonskeet@google.com>

* Update per April meeting feedback.

* formatting while checking grammar

* updates from 5/17 committee meeting.

* remove blank line.

* fix warnings

---------

Co-authored-by: Bill Wagner <wiwagn@microsoft.com>
Co-authored-by: Jon Skeet <jonskeet@google.com>

* C# 7.x: in parameter mode (#219)

* Update basic-concepts.md

* Update variables.md

* Update conversions.md

* Update structs.md

* Update interfaces.md

* Update delegates.md

* Update unsafe-code.md

* Update documentation-comments.md

* Update classes.md

* Update expressions.md

* include support for local functions

* fix merge tag

* fix build warnings

* build fixes

* build fixes, round 1

* build fixes, part 2

* one last link fix

* light edits based on earlier feedback.

* respond to remaining feedbac,.

* one final edit....

* clarification on `ref` extension methods

* Apply suggestions from code review

Co-authored-by: Jon Skeet <jonskeet@google.com>

* respond to feedback

* Update standard/expressions.md

Co-authored-by: Jon Skeet <jonskeet@google.com>

* Update standard/expressions.md

* Apply suggestions from code review

Co-authored-by: Jon Skeet <jonskeet@google.com>

* Update per April meeting notes.

* respond to feedback.

* Exclude dynamic implicit conversions

A dynamic expression can't be passed as an `in` parameter if an implicit conversion is required.

* Clarify restrictions on `in` parameters

Dynamically bound expressions can't use the `in` modifier.

* Apply suggestions from code review

Co-authored-by: Neal Gafter <neal@gafter.com>

* Updates from 5/17 committee meeting.

* fix warning

---------

Co-authored-by: Bill Wagner <wiwagn@microsoft.com>
Co-authored-by: Jon Skeet <jonskeet@google.com>
Co-authored-by: Neal Gafter <neal@gafter.com>

* C# 7.x: Add initializer list to `stackalloc` (#238)

* Update unsafe-code.md

* Update unsafe-code.md

* Move most of stackalloc spec from unsafe to here

* Impact of moving most of stackalloc spec from unsafe to expressions

* Moved most of stackalloc spec to expressions

* Fix links to new stackalloc spec location

* Add Span & ReadOnlySpan types

* fix build issues

* address feedback

* Stack initializers are only allowed as local variable initializers

This clarifies and simplifies some of the language for this PR.

* fix markdown lint issue

* respond to feedback.

* fix build issues

* one more round of build issues

* respond to feedback.

* decisions from 5/17 meeting.

* add safe context rules.

---------

Co-authored-by: Bill Wagner <wiwagn@microsoft.com>

* fix build warnings

* Apply suggestions from code review

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* fix references

* add closing backticks

One grammar rule was missing the closing backticks.

This caused several build errors.

* respond to feedback through clause 15 (classes)

This commit responds to feedback with the 👍 emoji through clause 15.

* respond to feedback.

* Apply suggestions from code review

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* rearrange conditional specification

* Update standard/expressions.md

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* Update standard/variables.md

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* edits based on feedback.

* Update standard/expressions.md

Co-authored-by: Jon Skeet <jonskeet@google.com>

* respond to feedback comments

* Apply suggestions from code review

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* more feedback

* Update standard/classes.md

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* Update standard/classes.md

Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>

* Update standard/expressions.md

* Update standard/expressions.md

* Update standard/expressions.md

Co-authored-by: Bill Wagner <wiwagn@microsoft.com>

* Update standard/variables.md

* edits during the meeting.

* Update standard/expressions.md

Co-authored-by: KalleOlaviNiemitalo <kon@iki.fi>

* edits, part 1

* respond to meeting discussion and feedback

Address all remaining conversations for this PR.

Addresses feedback from 06/05/2023 ECMA committee meeting.

---------

Co-authored-by: Jon Skeet <skeet@pobox.com>
Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>
Co-authored-by: Neal Gafter <neal@gafter.com>
Co-authored-by: Neal Gafter <nmgafter@fb.com>
Co-authored-by: Jon Skeet <jonskeet@google.com>
Co-authored-by: Rex Jaeschke <rex@RexJaeschke.com>
Co-authored-by: KalleOlaviNiemitalo <kon@iki.fi>
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.

8 participants