-
Notifications
You must be signed in to change notification settings - Fork 86
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
Different reference types: nullable and non-nullable #1124
Different reference types: nullable and non-nullable #1124
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More comments, but I think we're making progress :)
9cdf304
to
53d837a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments on updates per feedback.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting there :) Sorry to keep picking nits, but I'm definitely keen on getting this one over the line rather than the alternative that has null-oblivious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I like this approach better than #1105, but do see some issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few language changes, some comments to consider.
As with #1123 I am recommending we don’t merge this, we get it to a state we’re currently happy with, move on to others in the group, circle back around as needed, and then merge/reject the group as a whole.
We may need three types, not two. For example: void f(
#nullable disable
string x, // could x (oblivious) be seen as nullable type but non-nullable initial state?
#nullable enable
string y,
string? z)
{
if (...) {
// x state is not null? or oblivious?
g1(ref x); // okay
g1(ref y); // not okay
g1(ref z); // okay
// x state is possibly null
} else {
// x state is not null? or oblivious?
g2(ref x); // okay
g2(ref y); // okay
g2(ref z); // not okay
// x state is possibly null
}
}
void g1(ref string? x) {}
void g2(ref string x) {} |
Very short version: f("x", "y", "z");
void f(
#nullable disable
string x,
#nullable enable
string y,
string? z)
{
y = x; // no warning
y = z; // warning. Assignment of null to non-nullable variable.
} |
Example of why I believe it makes sense to view a variable of type T declared in a nullable-disabled context as a nullable type: # nullable disable
string x;
# nullable enable
x = "some value";
x = null; This does not issue a warning, even for the last line. The state of |
#nullable enable
string s = M();
#nullable disable
// What is the type of the return value?
string M() => null; |
7fb7b7e
to
137a8d2
Compare
Note that from 2024-8-20 through 2024-09-03, there was a lengthy thread on email re this topic, under the subject "ECMA TC49-TG2 agenda for September 4th." |
82f075e
to
06145dd
Compare
The first commit ports in the text from dotnet#700 substantially without change. The only editorial change is to move the clause on "Nullable directives" in lexical-structure before the clause on Pragma directives.
This will likely cause new failures, as I turned on nullable annotations and warnings in one of the templates. Update code samples for the template in use to remove nullable warnings. I did this as we plan to have nullable annotations on by default in this version of the spec.
At our September meeting, we decided that the standard should limit its normative text to the syntax required for nullable reference types, and a basic description explaining that the purpose of the annotations is to provide diagnostics.
0e001e0
to
346a776
Compare
This makes sense to add to this PR logically.
I think this may fix the left recursion error as well. Even if it doesn't, it's still correct.
State the nullable type for implicitly typed variables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comments during our meeting
Co-authored-by: Jon Skeet <skeet@pobox.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Big step forward :)
Additional edits from comments at the Oct 2 meeting. This resolves all open concerns.
I've addressed all open comments, and resolved all conversations. This is ready for a final (asynchronous) pass and approval. @jskeet @Nigel-Ecma @MadsTorgersen @ericlippert @RexJaeschke @gafter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a missing word and a one word change suggestion.
Co-authored-by: Nigel-Ecma <perryresearch@zoot.net.nz>
Fixes #1089
Fixes #1090
This is an alternative to #1105
The changes were done on top of the branch for #1105. The final commit has the updates to remove null oblivious types.
It removes the text for a "null-oblivious" type. Instead, it relies on the nullable context for how to interpret the nullability of a reference type
T
.