I found a topic on MSDN that talks that yes, this is possible.
I did a test that seems to break this statement:
using System; namespace Test { class Program { static void Main(string[] args) { Foo f = new Foo("1"); Console.WriteLine(f.Bar); // prints 1 f.Test("2"); Console.WriteLine(f.Bar);// successfully prints 2 } } class Foo { public Foo(string b) { this.Bar = b; } public string Bar { get; private set; } public void Test(string b) { // this would be impossible for readonly field! // next error would be occur: CS0191 or CS0191 // A readonly field cannot be assigned to (except in a constructor or a variable initializer) this.Bar = b; } } }
Where am I wrong?
Auto-implemented properties enable you to quickly specify a property of a class without having to write code to Get and Set the property.
Read only means that we can access the value of a property but we can't assign a value to it. When a property does not have a set accessor then it is a read only property. For example in the person class we have a Gender property that has only a get accessor and doesn't have a set accessor.
Auto-implemented properties declare a private instance backing field, and interfaces may not declare instance fields. Declaring a property in an interface without defining a body declares a property with accessors that must be implemented by each type that implements that interface.
In a field declaration, readonly indicates that assignment to the field can only occur as part of the declaration or in a constructor in the same class. A readonly field can be assigned and reassigned multiple times within the field declaration and constructor.
The answer below was written back in 2010. In C# 6 (released in 2015) you can write read-only automatically-implemented properties:
// This can only be assigned to in a constructor public int Foo { get; }
You're absolutely right. Properly read-only automatically implemented properties are currently impossible. Making the setter private isn't the same thing, regardless of what some books and MSDN might say :)
If I ruled the world, this would not be the case. When I see some of the language designers at NDC 2010 in June (please come along!) I intend to try to persuade, bribe, cajole and generally make a nuisance of myself until they agree. It's just one wafer-thin feature, after all.
Looking at that MSDN article, the text itself doesn't say that it creates a read-only automatic property. It creates an immutable type using an automatic property, and that's correct. The only problematic bits are the comments saying
// Read-only properties.
... which are definitely wrong. The framework agrees with us:
var prop = typeof(Contact).GetProperty("Name"); Console.WriteLine(prop.CanWrite); // Prints True
The property is read-only outside the Foo
class. I think that's what article is getting at.
But it's not the same as marking a variable with the readonly
keyword.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With