[Proposal] Auto-implemented interface properties

[hypeartist]

Imagine we have an interface:

public interface IRectangle<TCoord>
	where TCoord : unmanaged, INumber<TCoord>
{
	TCoord X1 { get; set; }
	TCoord Y1 { get; set; }
	TCoord X2 { get; set; }
	TCoord Y2 { get; set; }
}

Then in every struct implementing the above interface we have to explicitly define those properties:

public struct RectangleI32 : IRectangle<int>
{
   public int X1 { get; set; }
   public int Y1 { get; set; }
   public int X2 { get; set; }
   public int Y2 { get; set; }
}

My proposal is to allow omitting implementation of such trivial auto-properties and just generate their backing fields behind the scenes:

public struct RectangleI32 : IRectangle<int>
{
}

In case if some of those properties need some logic or just to be non auto-property then they could be implemented explicitly as usual.

[tacosontitan]

I'm not a fan of mixing implicit implementation with explicit (e.g. some is done for me and some is not), it should be all implicit or all explicit in my honest opinion. In this situation, imagine if, instead of working with a struct, you are working with a class:

public abstract class Rectangle<TNumber>
    : IRectangle<TNumber>
    where TNumber : unmanaged, INumber<TNumber>
{
	TNumber X1 { get; set; }
	TNumber Y1 { get; set; }
	TNumber X2 { get; set; }
	TNumber Y2 { get; set; }
}

public sealed class RectangleI32
    : Rectangle<int>;

I think instead of asking for partially implicit implementation of interfaces on structs, perhaps abstract struct would be more useful. Granted, I don't work with struct enough to weigh in on what kind of impact that would have.

[hypeartist]

I'm not a fan of mixing implicit implementation with explicit (e.g. some is done for me and some is not), it should be all implicit or all explicit IMHO.

(I prefer explicit, for clarity.)

Well, actually regular properties and auto-properties are also of that kind of mixing implicit implementation with explicit

[tacosontitan]

That's not quite accurate; the getter and setter methods still have visibility a la get; set; so it's a simplification, not a partial implementation like the OP's current request. If we wanted partial implementations, then IMHO we should ask for abstract support for struct since you can already partially implement an interface for classes with abstract class.

[jnm2]

Similar to the visibility role of get; set;, there could be a keyword preceding the interface type activating this automatic implementation.

An attribute on the class itself would enable a source generator to do this same thing though, and you can make that source generator today without waiting years for discussion and implementation of a new language feature.

[hypeartist]

An attribute on the class itself would enable a source generator to do this same thing though, and you can make that source generator today without waiting years for discussion and implementation of a new language feature

I think it's not possible as of today since there is no partial properties support atm. And even if it was possible I'd have to define them first in my struct.

[HaloFour]

You wouldn't need partial properties, the source generator could emit the full auto-properties corresponding to the unimplemented properties of the interface.

[hypeartist]

Oh, that sounds nice and looks like the thing I definitely should to try! Thank you for the idea!

[HaloFour]

Check it out, Visual Studio has an option to do this automatically: