Avoiding the cost of "fixed" when a struct is known to be situated in unmanaged memory.

[The-Futurist]

Methods in structs that need to get their own address (&this) currently can only do so within a fixed statement. This could be avoided if the struct were somehow annotated in such a way that it could never be situated in the managed heap.

Perhaps unmanaged or fixed or something, could be added as an option when declaring a struct. Any attempt to declare a field of this type inside a class (or nested inside other structs inside a class) would fail. Because the struct can be guaranteed to never be situated in the managed heap, it will be safe to allow methods and properties in these structs to avoid the overhead of using fixed when getting their own address.

Thoughts?

[HaloFour]

Isn't that already ref struct?

[CyrusNajmabadi]

While the restriction could be lifted, I don't really see much motivation. Writing a 'fixed' statement is trivial, so it's not a substantial burden to keep the status quo here.

[The-Futurist]

But isn't there a performance cost, needless too in this scenario?

[CyrusNajmabadi]

I don't see why there would be. Ref structs shouldn't move. What performance issue are you observing? If there is one, the runtime would be the right place to investigate and do something, not the language.

[The-Futurist]

No data, I just assumed that there is a cost and of one needs to do this a lot that cost would accrue. That aside, this surely is a language issue because it insists on the developer doing something that is pointless and unnecessary - or so it seems to me.

[CyrusNajmabadi]

Absent data, I don't see any need to change things here. It would be high cost for marginal (or zero) gain.

or so it seems to me.

Language changes are enormously costly. We don't do them unless we think there is substantial gain to the ecosystem as a whole. Having to write this construct is on the order of a paper cut. Investments in something like that doesn't really make sense given all the other areas we can focus on.

If you have an actual perf issue here, I would bring it up with the runtime first so we can see what they think. If this cannot be solved there and there is substantive need, we can look at the lang or compiler side. The latter also seems fine to me. The lang could require this, but the compiler could no-op it

[The-Futurist]

Also, unsafe code cannot appear inside iterators, if this is related to the possibility of the GC messing up the iterators state, then could this too be changed so that if the unsafe code is only accessing a ref struct it's safe to allow iterators?

Eric Lipper explains that (apart from it being in bad taste) it is because of the GC and the need to perhaps pin something for the duration of the enumeration, so again if the unsafe code is only accessing a ref struct this could be allowed - in principle.

Imagine a scenario where we need to walk raw memory, perhaps an unmanaged linked list or something, this is a use case.

[huoyaoyuan]

It's almost the opposite. Don't think async methods to be methods, they are state machines.

Direct fixed pointer is additional task for GC. Indirect pins can already be achived via GCHandle. Ref struct with state machine is fundamentally incompatible.

[The-Futurist]

@huoyaoyuan

See:

dotnet/roslyn#2143
#510

[The-Futurist]

If we have a fixed field array and I simply want to enumerate it, expose it through some public property, I cannot do so.

[CyrusNajmabadi]

What stops you in this case? Can you link to the code you're using to try this to do this?