Get-only properties are emitted as readonly in CoreFx ref assemblies

Get-only properties are generated as readonly properties when auto-generating ref assemblies. The autogeneration steps are as mentioned in updating-ref-source.md. This causes multiple changes in the ref assembly code; not sure if it is legit and should be accepted.

E.g.

-        public bool AllowTrailingCommas { get { throw null; } set { } }
-        public System.Text.Json.JsonCommentHandling CommentHandling { get { throw null; } set { } }
+        public bool AllowTrailingCommas { readonly get { throw null; } set { } }
+        public System.Text.Json.JsonCommentHandling CommentHandling { readonly get { throw null; } set { } }

And another one with subtle difference

-        public System.Buffers.ReadOnlySequence<byte> ValueSequence { get { throw null; } }
-        public System.ReadOnlySpan<byte> ValueSpan { get { throw null; } }
+        public readonly System.Buffers.ReadOnlySequence<byte> ValueSequence { get { throw null; } }
+        public readonly System.ReadOnlySpan<byte> ValueSpan { get { throw null; } }

Entire diff can be found here.

Creating this issue based on discussion in dotnet/corefx/issues/36125 in following comments, _@WinCPP in https://github.com/dotnet/corefx/issues/36125#issuecomment-500109703_ _@ahsonkhan in https://github.com/dotnet/corefx/issues/36125#issuecomment-500173705_

[tannergooding]

I will have to spend some understanding this feature a bit better, particularly potential drawbacks (https://github.com/dotnet/csharplang/blob/master/proposals/readonly-instance-members.md#drawbacks), so let me get back to you.

The drawbacks are just the same as not having the attribute, there are some cases which may still have hidden copies due to how the compiler handles things. This is more a concern about the implementation within a member marked readonly though, and in that you will get an compiler error if you try to invoke a non-readonly method (which just forces you to create an explicit copy).

Also, to summarize what @ahsonkhan asked me offline.

• The attribute can exist for downlevel as well. Compilers that don’t understand the attribute will simply ignore it. So, something using C# 7.3 will consume the ref assembly that has the attribute and it will ignore it and potentially create hidden copies in applicable scenarios (the same as if the attribute didn’t exist at all). C# 8.0 and higher will consume the ref assembly and recognize the attribute, eliding the hidden copies in applicable scenarios.

[WinCPP]

Thanks @tannergooding for the info. Closing this issue as discussed above.