[Feature-Request]: Allow 'required' keyword for properties in an interface

[CodingMadness]

Imagine you have an interface with 2 Properties (Text, Color) which is being used by 4 implementors, and what all these 4 have in-common is that they all NEED the Text Property at construction-time in order to properly function, and the Color one is not of importance at construction time.

Sadly right now I have a similar case where all 4 structs MUST be built with that Text Property so I need to mark in the implementor-structs each with the required keyword which is really tedious work..

Have a look:

1. Problem - Clutter (must be repeat for every struct and is more error prone; Breaks the DRY-pattern)

public struct StructA : ITextInformation {  
    public required Span<char> Text { get; init; }

public struct StructB : ITextInformation {  
    public required Span<char> Text { get; init; }

public struct StructC : ITextInformation {  
    public required Span<char> Text { get; init; }

public struct StructD : ITextInformation {  
    public required Span<char> Text { get; init; }
}

---

2.Problem - Cant use abstract classes

public abstract class TextInformation 
{
      public required Span<char> Text { get; init; }
}

public struct StructD : TextInformation   //obvisiouly not allowed! 
{
        
}

---

3. Problem - Need to rely on the runtime to do the validation if init of the property was forgotten (less safe than on compile time of course)

public struct StructA : ITextInformation {  
    public Span<char> Text { get; init; }  
    public MyStruct() {  
        if (Text is []) throw new InvalidOperationException("Text must be initialized!");  
    }  
}  

First-Class-Constructs:
Structs should have 'First-Class Contracts', because they cannot make use of inheritance, so interfaces are their only mechanism for shared contracts + initialization rules and yes it is doable with Roselyn and 3rd party tools and such already but this (if deemed worthy) mustthen be set on a compiler level where it (then) would belong due to it being such a widely useful scenario.

Design-Philosphy deprecated (imho):
"interfaces should only declare behavioral, not construction rules" being able to enforce that a value HAS to be set at INITIALIZATION-TIME is still not forcing the user HOW he should create the type nor if its inside the constructor or via other (new) init construction syntaxes we have now; this is still the implementors choice and it ignores real-world needs for initialization guarantees in value types.
When the Compiler can enforce himself 'required' in all the implementors, It would prevent entire load of bugs.

The Tech is already there
Since what I propose here is already doable with usual types, adding it on interface-level should be a no-brainer

No breaking change
'required' would only be opt-in and hence existing interfaces just wouldn’t use it.

You would have:
- Guarantee: All X-structs (like in this example, 4) are initialized identically.
- Safety: Compile-time errors if Text isn’t set.
- DRY Principle: Contract defined in one place.

I hope to hear from you all and especially from the Compiler-team themselves of course and listen to some feedback :--)

[huoyaoyuan]

required is only meaningful with constructors. Interfaces are unrelated to constructors.

[CodingMadness]

Sorry but this reply feels hard like as you did not even bother to (fully) read it, no?

I have made actually very clear why they could make for another very important layer of 'contraction' for the reasons and details explained in my proposal.

[CodingMadness]

Interfaces should be able to define construction-rules in the sense that they should be able to force the implementors to initialize them on creation but the details in how to do that and where and what data comes to them is still a mistery for the interface so thats absolutely fine and not 'philosophy breaking' so to speak.

[IS4Code]

required is only meaningful with constructors. Interfaces are unrelated to constructors.

You are factually incorrect:

interface I
{
    int X { get; init; }
}

class C
{
    public static T Construct<T>(int val) where T : I, new()
    {
        return new T()
        {
            X = val
        };
    }
}

Here required would definitely make a difference. I am however unsure if there is a point to enforcing required for implementations ‒ a class should always be allowed to extend its capabilities past those required by the interfaces it implements, and not requiring setting a property (i.e. having a viable default value) is one such example.

[DanielShuey]

I agree, we should have inheritance for Structs, abstract Structs, etc.

Semantically it's weird, so you could also get rid of structs and allow classes to be allocated on the stack.

Or use composition but implement syntactic sugar to batch forward methods.

---

Compared to the pessimism in Java forums, C# is really great in that they continue adding a lot of features.

However something I find frustrating is they tend to implement alternative versions (the C# way) of a language feature, which just aren't as good as the original or desired solution. This causes more features needing to be added to cover the areas the last feature missed.

E.g Extension methods, default interface methods, etc. Just have Mixins or multiple implementation inheritance. It would be nice for once to just take the "risk" and go for the simpler more comprehensive solution.

I think it's due to fear.

I think many of the fears of software design are completely overblown.

Java gained a reputation for creating huge bloated code-bases after trying to be an improvement over C++. The bad developers who blamed C++ as the problem, moved their crap to Java and then Java became the new punching bag for programmers. The issue lies with the developer(s).

I have worked on large teams with Ruby and Mixins, it was never a problem. I am working on a complex project which mostly uses pointers instead of refs (ideally all pointers soon), in a multi-threaded app. I am yet to see the benefit of refs over pointers. I think I've just been brainwashed into thinking using pointers is difficult.

I was also brain washed into being afraid of the Diamond problem. It's practically impossible to run into the Diamond problem if your knowledge of OO is good enough. Each domain tends to use its own language, you can only really have conflict if you're not organizing your logic into each domain properly. There are cases where multiple implementation inheritance is the semantically correct design.

If your knowledge is bad, most likely the code-base will be bad no matter what. Who's seen an app almost entirely written into one class?

Yes yes goto-statement I know. :P (and ye olde ADT's)

[CodingMadness]

I agree to all except pointer (better than) ref's because with ref's afaik you cannot point to really random arbitrary memory places which is not even being init, refs always enfore valid objects (which are visually set to a value) and cant be "dangling" (hence the safe-2-escape) and so on..

But I really loved the principle of C++ and even Borland Delphi, where you had Classes on heap or struct because the pure Definition of the word "Class" should not determine its memory layout, only its semantics (shall it be a data-holder with minimal API, or actually only hold some data and nothing else or shall it be an entire factory so to say with a lifetime of the entire App itself and do complex heavy lifting in the background) and then BASED on how you answer these questions, you choose where to store this object (short lived, needed only for method scope => Stack; else Heap)

[HaloFour]

Definition of the word "Class" should not determine its memory layout, only its semantics

It does. The difference between class and struct in C# isn't whether the instance lives on the heap or the stack. The difference is whether the that type must be copied by value or copied by reference. Where they end up living is an implementation detail to facilitate that and the runtime may already allocate reference types on the stack.

[DanielShuey]

Thanks.

I had no idea, I used Delphi a little almost 20 years ago, and don't remember haha. Would be nice, it obviously has implications with backwards compatibility, but deprecating keywords to make room for improved language features would be cool.

Theoretically you're right, but I frequently have compiler issues with using refs as I run into arbitrary restrictions or my refs aren't placed right. It sounds great in theory, but it practice it's been a headache for non-trivial solutions. Your code ends up looking like ref struct; public ref Result Thing(ref id); ref var person = ref GetPerson(ref id); return ref person; ref ref ref ref.

Right now I'm using unsafe mode, pointers and allocating memory everywhere. It looks like normal code 😄 . It's heavily multi-threaded but it's standard debugging procedure, I'm not running into any weird memory address issues or anything like that. I'm deleting what's left of the refs.

I'm fully prepared to come back here admit that I'm wrong if I end up running into problems 😄, but multi-threading should be the biggest pain area. It's multi-threaded with IO even and a lot of analysis and transforming of data already. I'm not really getting any pain.

Tbf this is in Unity, but it's still mostly C# std lib.

[DanielShuey]

@HaloFour That's my bad. You're right, I've been using structs and pointers and using them similar to classes, when I use pointers as arguments they don't get cloned, so then I just forgot about it 😄.

I usually remember and look out for that when I do an optimization pass, but when I'm working on a feature I'm not really thinking about it.

Generally I think if it looks like a->b->c or Foo(Bar* baz) I'm in good shape.

[jnm2]

For classes vs struct, I like to say it as whether they control their own memory or have their memory inlined into a larger structure (array, class, etc).

[333fred]

I want to point out that we explicitly considered and rejected required members in interfaces for now: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-11.0/required-members.md#required-interface-members. There are some thorny issues here through generics, and to simplify the proposal we opted to not try and solve them for now. If someone were to come with a complete proposal for factories in C#, including required improvements, I'd likely be willing to champion it.