5

In this much-cited post, Eric Lippert explains that "The stack is an implementation detail".

So as I understand it, in the world of .NET, the major distinction is reference types vs value types.

But reading this introduction to the Span<> type, I see loads of references to 'Heap' and 'Stack'. Are these proxies for 'reference and value' in this context, or has the heap/stack distinction snuck back in?

Benjol
  • 63,995
  • 54
  • 186
  • 268
  • For me, it does not seem like it has. The `Span` still doesn't require you to know whether the thing it shows is on the stack or on the heap, so those are, again, Span's implementation details. It's just that when you find yourself doing this kind of optimisations, you are [kind of expected](https://stackoverflow.com/q/3883006/11683) to understand the implementation details... – GSerg Sep 18 '20 at 08:01
  • The point of Eric's article was to say that, *when* discussing value type vs reference type, the stack is irrelevant. In *that* context. Of course, the stack exists and the `stackalloc` keyword has long required it. In other contexts, such as the second article, Heap vs Stack may be relevant. – Damien_The_Unbeliever Sep 18 '20 at 08:03
  • I don't think so, all the talk about heap and stack in the article is explaining how `Span` is actially implemented. The only really singular thing about it is that it can't be boxed... but other than that, you can very well work with it and `Memory` without really having to know anything about how the memory model is implemented (just like with any other value and reference types). – InBetween Sep 18 '20 at 08:07

0 Answers0