#Aasync xmlreader code#

Thinking about it, the compiler doesn’t know when it compiles EvilReadXml that T is a readonly struct – it could be a regular struct. We have an in parameter in EvilReadXml, so the expiry variable is being passed by reference, and then we’re calling ReadXml on that parameter… so doesn’t that mean we’ll modify the parameter, and thus the underlying expiry field in the object? Var reader = XmlReader.Create(new StringReader(xml)) Static void EvilReadXml(in T value, string xml) where T : IXmlSerializable Ref readonly Instant expiry = ref accessToken.Expiry Static void MutateAccessToken(AccessToken accessToken)

#Aasync xmlreader code#

Here’s code I expected to mutate the access token: The big test is: can we break this friendly’s code’s assumptions about expiry really not changing its value? Great – it lets you get at the expiry time of an access token without even copying the value. Public AccessToken(Instant expiry) => this.expiry = expiry Public ref readonly Instant Expiry => ref expiry Here’s a class we’ll put in a “friendly” assembly which is trying to be as helpful as possible: Let’s try to abuse our “slightly dodgy” implementations. Now let’s look at the knock-on effects… Safe code trying to abuse the unsafe code That’s a pity, but if we can make everything else readonly, that’s a good start. Throughout Noda Time, and think about what would happen…Īs it happens, that fix doesn’t work universally: ZonedDateTime is a “managed type” because it contains a reference (to a DateTimeZone) which means you can’t create a pointer to it. Just for kicks, let’s apply the same change Unsafe void IXmlSerializable.ReadXml( XmlReader reader)Įssentially, the unsafe code is bypassing the controls around read-only structs. Here’s the code that compiles when LocalTime is marked as readonly, after enabling unsafe blocks: String text = reader.ReadElementContentAsString() Var pattern = LocalTimePattern.ExtendedIso Preconditions.CheckNotNull(reader, nameof(reader)) Void IXmlSerializable.ReadXml( XmlReader reader) To give a concrete example of the answer from Stack Overflow, here’s my current LocalTime code: It even has an answer! Unfortunately, it amounts to a workaround: assigning to this via unsafe code.

But how can we fix that? Like any sensible developer, I turned to Stack Overflow, which has precisely the question I’m interested in. That’s reasonable: in members of a readonly struct, this effectively becomes an in parameter instead of a ref parameter. But every struct that implements IXmlSerializable gave me this error:Ĭannot assign to ‘this’ because it is read-only To be fair, some of the structs (7 out of 18) were fine. At last, I can remove my ReadWriteForEfficiency attribute! Hmm. I relished news of the readonly modifier for struct declarations. Adding the readonly modifier to Noda Time structs With a generic method using an interface constraint you can observe a simple method call mutating a non-read-only variable, but that’s generally harmless. I use explicit interface implementation to make this less likely to be used directly on an unboxed variable. Noda Time implements IXmlSerializable.ReadXml by assigning to this: fundamentally IXmlSerializable assumes a mutable type. Noda Time includes many value types which implement IXmlSerializable. The ref readonly local variables and in parameter features in C# 7.2 mean that “read-only variables” are likely to be more common in C# than they have been in the past. I was touched to see that the proposal references my blog post :) See the language proposal for more details. C# 7.2 addresses this by introducing the readonly modifier for structs.

I’ve written about this before on this blog. Operations on read-only variables which are value types copy the variable value first. There are three things you need to know to start with: