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

Declare readonly members for mutable structs #39637

Merged
merged 1 commit into from
Mar 24, 2022

Conversation

JamesNK
Copy link
Member

@JamesNK JamesNK commented Jan 19, 2022

Copy link
Contributor

@pranavkm pranavkm left a comment

Choose a reason for hiding this comment

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

Looks alright to me.


public int MethodEnd => (int)(uint)(_versionAndMethod >> 32);
public readonly int MethodEnd => (int)(uint)(_versionAndMethod >> 32);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a public type is in an internal namespace? There is some discussion in the runtime about how changing a readonly member to non-readonly in a later version would be considered a breaking change: dotnet/runtime#1718 (comment), something to be aware of.

Copy link
Member Author

Choose a reason for hiding this comment

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

TIL it is a breaking change to remove readonly from structs.

I don't see a scenario when these properties would ever not be readonly so I think this is fine.

@davidfowl
Copy link
Member

What are the other implications of this? Any gotchas to be worried about?
cc @stephentoub

@stephentoub
Copy link
Member

What are the other implications of this? Any gotchas to be worried about? cc @stephentoub

At the member level, there aren't really any gotchas other than compat. It's not a breaking change to make a member readonly, but it is a breaking change to remove readonly from a member, so applying readonly to public members on public types is signing up to have that member be readonly forever more. Other than the implications of that, and the tiny additional amount of metadata that comes from [IsReadOnly], there aren't really downsides.

As an aside, note that the C# compiler implicitly marks get-only auto-props as readonly. You can see here for example that it's emitting [IsReadOnly] on the getter.


object IEnumerator.Current => _current;
readonly object IEnumerator.Current => _current;
Copy link
Member

Choose a reason for hiding this comment

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

Undo?

Copy link
Member Author

Choose a reason for hiding this comment

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

Reason?

@@ -243,11 +243,11 @@ internal Enumerator(HttpRequestHeaders collection)
: default;
}

public KeyValuePair<string, StringValues> Current => _current;
public readonly KeyValuePair<string, StringValues> Current => _current;
Copy link
Member

Choose a reason for hiding this comment

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

Undo?

Copy link
Member Author

Choose a reason for hiding this comment

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

Reason?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

The comment is about backwards compat which doesn't apply here because this type is internal. And about auto-properties which doesn't apply because these aren't auto-properties.

You're going to need to provide more detail.

Copy link
Member

Choose a reason for hiding this comment

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

It was about this #39637 (comment)

@mkArtakMSFT
Copy link
Member

@JamesNK looking through the comments looks like this is in relatively good shape. The only potential blocker here is the last comment from @davidfowl, and that thread seem to have died. @davidfowl can you please follow up? Thanks!

@JamesNK JamesNK force-pushed the jamesnk/struct-readonly-members branch from 059f764 to 42740b7 Compare March 24, 2022 04:58
@JamesNK JamesNK merged commit 55a5316 into main Mar 24, 2022
@JamesNK JamesNK deleted the jamesnk/struct-readonly-members branch March 24, 2022 09:45
@ghost ghost added this to the 7.0-preview3 milestone Mar 24, 2022
@dougbu dougbu modified the milestones: 7.0-preview3, 7.0-preview4 Apr 5, 2022
@amcasey amcasey added area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions and removed area-runtime labels Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-networking Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants