Allow mixing "init;" and "private set;"

[lucasteles]

Sometimes we want our class public API to be immutable as possible and delegate all state management to the class itself.
The combination of required and init is very handy on this, but today it is not easy to have an init property with private set;/protected set';

Would be nice to have a simple way to do this.

Some ideas:

public class Foo1
{
    public required string Value { get; init and private set; }
    public void Update(string value) => Value = value;
}
public class Foo2
{
    public required string Value { get; init with private set; }
    public void Update(string value) => Value = value;
}
public class Foo3
{
   // just allow both with some precedence
    public required string Value { get; init private set; }
    public void Update(string value) => Value = value;
}
public class Foo4
{
    public required string Value { get; init, private set; }
    public void Update(string value) => Value = value;
}
public class Foo5
{
    [AllowSet(Visibility.Private)]
    public required string Value { get; init; }
    public void Update(string value) => Value = value;
}

When mixing init and set should have a constraint that the set must be less accessible than init

[HaloFour]

The init accessor method is really the set accessor method with additional metadata applied to it via modreq to indicate when/where it could be called. I don't think you could have a separate accessor method here, but you could potentially have the metadata inform the compiler that the method could be called in other circumstances. For a private set scenario that should be easier since it's in the same compilation unit and does not need to impact the external metadata of the accessor.

[lucasteles]

Maybe an attribute?

[TahirAhmadov]

Can you cite an example of how these classes would be used?

[brendonparker]

My use case would be for EF where I want to insulate the entity such that state can only be changed from within (i.e. private set;), but I also want to be able to initialize the properties. So, the ability to initialize state to whatever (for purpose of saving to database), but then allowing the entity to restrict what changes are made after the fact (for writes going forward).

Perhaps combined with record types, this gives some flexiblity, especially around testing. For an immutable record type, can't modify the state of the object, but you can create a copy (using the with) syntax. This makes setting tests up easier. Its a bit of a lazy approach, I suppose, as you're working around needing to fully setup the object and go through business logic.

Concrete (yet contrived) example:

public record Order
{
    public required long Id { get; init; }
    public required string Status { get; init private set; }
    // Other fields here that may be related to Status ...
    
    public void StartProcessing()
    {
        Status = "Processing";
        // More logic here touching other properties,
        // Requiring certain state to be setup
    }
}

Order order = new() { Id = 0, Status = "Queued" };
order.StartProcessing();

// Ideally, could also do this, to get the same order, but with the Status set to Processed:
Order order2 = order with { Status = "Processed" };

order2.Status.Should().Be("Processed");

[DavidArno]

Since the following is already possible:

public class Foo1
{
    private string _value;
    
    public required string Value 
    { 
        get => _value; 
        init => _value = value; 
    }

    public void Update(string value) => _value = value;
}

I'd question the value of this proposal. The occasions where you want public init, private set and provide a public method to work around that public init seem likely to be vanishingly rare. As @TahirAhmadov asks, do you have a real-world use case for where having a public set causes a problem which this proposal then solves?

[DavidArno]

@FaustVX, the question still stands: what is the problem that this is trying to solve? What's wrong with just having a public set, especially when we get the field keyword?

[FaustVX]

What's wrong with just having a public set,

Because we don't want the outside to modify the value after it's creation, but still want the possibility to modify it inside the class.
I have already wanted this feature some time ago, but I can't remember what it was.

[lucasteles]

@FaustVX exactly

[lucasteles]

@DavidArno The compiler will emit a warning on your code snippet also: Non-nullable field '_value' is uninitialized. Consider declaring the field as nullable.

[333fred]

Only a minor modification needed:

public class Foo1
{
    private string _value;
    
    public required string Value 
    { 
        get => _value; 
        [MemberNotNull(nameof(value))]
        init => _value = value; 
    }

    public void Update(string value) => _value = value;
}