为什么属性只能包含C＃中接口类型的setter？

Question

I wonder why in C# it is not allowed to use only { set } property in auto-generated property in class type like:

class Person {
    public string Name { set; } // Compile-time error
}

However, it is allowed in interface type:

interface IPerson {
    string Name {set;} //Allowed
}

I read similar question here , it is very rare practice - what I understand, but I wonder why CLR even allow to do it?

Answer 1

For one simple reason. If you're using an Auto implemented property (Hidden private field generated). Then why would you need to set a value that you would never be able to get (and subsequently use).

For the Interface, you're not using an auto implemented property, it is just a contract specifying that the implementation class should have a string property named Name that should implement a Setter method. So, you can do this:

interface IPerson
{
    string Name { set; }
}

class Person : IPerson
{
    private string _name;
    public String Name
    {
        set { _name = value; }
    }
}

So in conclusion, the C# compiler is trying to prevent us from doing something that doesn't make any sense which is: Providing an auto set method for a private hidden field that can never be get.

Answer 2

Because what is the point of a property you can assign a value to but have no way to observe it?

The following is perfectly legal

class Person {
    private string _name;
    public string Name { set { _name = value } }
}

The reason the auto property doesn't let you do it is because you could never get the value out after it was written, with a manual implemented property you have the chance to set the value to some other field.

The reason interfaces allow it is so the interface can describe manually implemented versions or auto implemented ones with public string Name {private get; set;} public string Name {private get; set;} .

Answer 3

You're using an autoproperty in your class, which is defined as having a hidden private field that is accessible using a getter.

If you're just using a normal property, you can absolutely have only a setter:

    public string Name {
        set {
            Console.WriteLine("hi");
        }
    }

Answer 4

class Person {
    public string Name { set; } // Compile-time error
}

The backing field is inaccessible, so there is no way to get it. It's explained in the C# specification that since there is no point in having one without the other, it is disallowed.

Because the backing field is inaccessible, it can be read and written only through the property accessors, even within the containing type. This means that automatically implemented read-only or write-only properties do not make sense, and are disallowed. It is however possible to set the access level of each accessor differently.

The compiler team made a call that it would be better to not allow it, since there is no point and by allowing it, developers can potentially write more error prone code.

They make the same judgement call in other areas of the language too, such as not allowing fall through most of the time in case statements. (you can fall through a case with no code in it). Technically, in that instance you could say it provides benefit, but they felt that the benefit did not outweigh the potential error cost.

Answer 5

The interface is only to make sure that your class is implementing the method. However, when you are creating a class, there is no point of having a property that you can never get