[Proposal]: Value Class

[redradist]

Value Class

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Value class that make behavior of class the same as struct, but instead of similar feature records Value Class allocated on stack

Motivation

Make C# more value oriented for performance benefits

Detailed design

value class MyCustomClass : CustomClassBase
{
   ...
}

For class MyCustomClass all fields allocated on the stack including fields of base classes in hierarchy

Drawbacks

For class with deep inheritance chain could use to many memory on stack

Alternatives

Unresolved questions

Design meetings

[CyrusNajmabadi]

Moved to a discussion. This would need a lot of explanation on how this would actually work, esp. given the existing capabilities and featureset of the .net runtime. Thanks! :)

[HaloFour]

And the known limitations of inheritance of value types. There's a reason .NET doesn't permit allocating classes on the stack, it creates a lot of problems which are evident in the languages that do permit it, like C++. It becomes impossible to know the actual size of the object since it can be a derived type, but the compiler and runtime must know the actual size of the object. Otherwise you will invariably run into decapitation and shearing scenarios. It becomes impossible to something as simple as indexing to a specific element in an array because you have no idea how large each element might be.

[redradist]

And the known limitations of inheritance of value types. There's a reason .NET doesn't permit allocating classes on the stack, it creates a lot of problems which are evident in the languages that do permit it, like C++. It becomes impossible to know the actual size of the object since it can be a derived type, but the compiler and runtime must know the actual size of the object. Otherwise you will invariably run into decapitation and shearing scenarios. It becomes impossible to something as simple as indexing to a specific element in an array because you have no idea how large each element might be.

@HaloFour Why it is impossible to know size ? C++ solves this by knowing the size of class at place of instantiation ...
Actually you are right in sense that for example for interface argument in function it is hard to implement knowledge if it is simple class or value class ... I need to think, maybe this feature is not deserve to work on, because could be changed with struct and composition instead of inheritance ...

[HaloFour]

@redradist

C++ doesn't solve it, which is why it's possible to have a Base[] and stick a Derived into it which will spill over and overwrite part of the other elements. Or to read an element into a Base which decapitates part of the Derived.

[redradist]

@redradist

C++ doesn't solve it, which is why it's possible to have a Base[] and stick a Derived into it which will spill over and overwrite part of the other elements. Or to read an element into a Base which decapitates part of the Derived.

C++ cannot allocate or store object of abstract type like Base ... it is only possible to do by reference ...
But anyway, I start thinking that this feature is not needed at all ...

@HaloFour Do you know if there is considered some suggestion for RAII semantic for structs in C# ?

[HaloFour]

@redradist

https://en.wikipedia.org/wiki/Object_slicing

Do you know if there is considered some suggestion for RAII semantic for structs in C# ?

#121

[YairHalberstadt]

@redradist

I really don't understand what you're actually proposing here?

Value class that make behavior of class the same as struct, but instead of similar feature records Value Class allocated on stack

You're saying you want something that has the same behaviour as a struct and is allocated on the stack. Isn't that just a struct?

[CyrusNajmabadi]

I think so. Except they want inheritance, which i can understand. I wouldn't mind if C# allowed for struct-pseudo-inheritance (potentially using go-style composition as the mechanism to achieve this). Now, having structs inherit from other classes, or having classes inherit from classes, but be stack allocated... i see the desire. But i don't really see any path to them (esp. not without potentially having really really bad stuff happen).

[YairHalberstadt]

I think have structs inherit from other structs is fine, so long as they can't be cast to an instance of the other structs, and polymorphism is done via type parameters.

[redradist]

I think have structs inherit from other structs is fine, so long as they can't be cast to an instance of the other structs, and polymorphism is done via type parameters.

@YairHalberstadt Yeah, it would be fine
I think the same way, that casting should be avoid because it will make harder to reason about size of argument in function

[HaloFour]

Inline classes in Java Valhalla are the same as structs in C#. They cannot participate in inheritance.

[redradist]

Inline classes in Java Valhalla are the same as structs in C#. They cannot participate in inheritance.

@HaloFour Yeah, seems like that ...

[PathogenDavid]

In my opinion this issue is really asking for two things in one: Stack-allocated objects and struct inheritance, but I don't see any reason the two features need to be combined.

The runtime has basic support for automatically stack-allocated objects. It assumes all objects passed as parameters will escape though it's not extremely useful yet. The general issue covering stack-allocated objects is dotnet/runtime#11192 (See also: dotnet/runtime#4584 )

For struct inheritance, see the previous discussion at #936

[HaloFour]

Last I checked the project to try to have the runtime automatically allocate reference types on the stack based on escape analysis had permanently stalled. There just wasn't enough demonstrated benefit and most scenarios could not benefit from it. It's notable that Java has had stack allocation with escape analysis since Java 7, and while it was deemed much more critical for Java due to the lack of non-primitive value types, it has still been considered a failure which is why Valhalla is seeking to add proper value types to the JVM.

[PathogenDavid]

Correct, the runtime issue is focusing on allocating on the stack automatically rather than manually. I reworded things slightly to make that more apparent.

My understanding of the Java issue isn't that automatically allocating objects on the stack was a failure, but rather it wasn't robust enough to use it for everything like Java did. I would think there's still some value in doing it.

[HaloFour]

I was referring to the project to have the runtime automatically allocate reference types on the stack. That's the project that has seemingly stalled due to the lack of benefit from the early prototypes.

dotnet/runtime#1661 (comment)
dotnet/runtime#4584 (comment)

Sounds like it will continue but would likely require a different tact or some kind of AOT/tiered approach. It'd be cool if it happens, but I'd be wary of depending on any feature like this as a means to eke out performance due to the lack of guarantees. It's like how the runtime will automagickally do tail recursion but the C# team is looking into making it a part of the language so that the developer can have some expectation as to when it will actually happen.

"We spent probably a good ten-plus years trying to figure out how to make VMs do escape analysis and we failed on that one too." - Brian Goetz, April 2019 link

Granted it was part of a presentation on Valhalla.

[PathogenDavid]

Yeah, we're both talking about the same thing. I'm not bringing it up as a reason to never add support to the language, but I don't think a discussion about stack-allocated objects would be complete without mentioning existing efforts from the runtime side of things.