struct validity broken by default

[HazyFish]

I want to use struct over class for performance purposes. However, I realized that the default of a struct type is always bytes of 0's regardless of how we init the fields in the parameter-less constructor. If I want to store a non-zero int field or a non-null string in my struct, how can I guarantee its validity without runtime overhead?

[CyrusNajmabadi]

If I want to store a non-zero int field or a non-null string in my struct, how can I guarantee its validity

Call a constructor that initialized it to have the values you want.

[CyrusNajmabadi]

Yes. that's the nature of structs. If you don't want that, use a class. Otherwise, have you members inside the struct check if they are in an unintialized state.

[HazyFish]

I'm sure there are plenty of types in .NET and maybe ASP.NET Core that also use struct to optimize performance. How do they approach this problem? Or are they designed to make bytes of 0's always a valid value?

From another point of view, it should be a solvable problem since Rust does not allow uninitialized struct values to be used. C# has done a good job of introducing null safety for reference types, and IMO we should also solve this problem to close a loophole in the type system where we can have a nullable "non-nullable" string field in a struct that the compiler won't complain about.

[CyrusNajmabadi]

How do they approach this problem?

If the zero-init state is not valid, they throw if you do something on that state.

From another point of view, it should be a solvable problem since Rust does not allow uninitialized struct values to be used.

Neither does C#. But in this case it is initialized, just initialized to 0.

and IMO we should also solve this problem to close a loophole in the type system

The loophoole here exists for null reference types as well. NRTs are just a best-effort notification system you can drive a truck through. We accept that as a fundament limtiation that cannot be solved withotu runtime checking. The same is true for value types.

[HazyFish]

Neither does C#. But in this case it is initialized, just initialized to 0.

You're right, but in Rust you cannot use default unless you explicitly allowing it by deriving the trait. We could do something similar by adding a modifier to the struct.

The loophoole here exists for null reference types as well. NRTs are just a best-effort notification system you can drive a truck through. We accept that as a fundament limtiation that cannot be solved withotu runtime checking. The same is true for value types.

I'm curious what's the reason to not having a long-term goal for closing them? Is it because it has to be a breaking change that we must compromise?

[CyrusNajmabadi]

I'm curious what's the reason to not having a long-term goal for closing them?

Because the cost to benefit ratio is terrible :) It's a tremendous amount of effort, to solve issues that will rarely be problematic in practice. Our efforts are far better spent elsewhere.

Is it because it has to be a breaking change

Yes. And given the choice of pretty much "breaking every program", versus "not breaking every program, but providing tools to eliminate hte majority of bugs" we're always going to go the latter route :)

[FaustVX]

That's intentional, default will zeroed all fields (null for class)
You can write an analyzer which emit an error on every struct instance, annotated with an attribute, assigned to default

S s = default;
//    ~~~~~~~ your error here

[NonDefault] // your attribute
struct S;

[TahirAhmadov]

Also keep in mind fields of this struct type, and arrays. Also, mutable collections like List<T> - calling Add(default).
I would be interested to see if anybody has already or is planning to make an analyzer like this, and to find out about all the challenges they faced in the process, and to test it out in my code.

[TahirAhmadov]

One "workaround" to slightly improve the situation is to declare explicit parameterless ctor on the struct and decorate it with [Obsolete(true)]. It doesn't guard against default, but at least it prevents new S() which absent an explicit parameterless ctor is synonymous with default(S).

[ufcpp]

#146

[HazyFish]

dotnet/runtime#98300 (comment)

[CyrusNajmabadi]

?