4

In this SO question: Why doesn't C# support the return of reference (and elsewhere on the web), I can't determine when ref return was introduced to the .NET framework. Is it just syntax sugar?

Reason I'm asking is that many of our hosts are not installed with latest .NET framework version (still on 4.5.2) and I'm wondering how this would affect CLR backwards compatibility, runtime correctness and performance.

Also, where would I be able to find documentation on how older .NET framework handles backwards compatibility? The C# 6.0 Language specification does not seem to cover this, perhaps I'm somehow skipping this?

Lews Therin
  • 10,907
  • 4
  • 48
  • 72

1 Answers1

5

As mentioned in the answer you linked to (and the blog entry this answer linked to), the .NET CLR has always supported ref returns, it's just that the C# and VB compilers did not support it.

C# 7.0 added support for reference return values, and VB 15 added partial support.

In other words: The .NET Framework version on your target system does not matter, the compiler version on your development system matters. There is no need for backwards compatibility, because, as mentioned above, the feature has been in the .NET CLR from the beginning.

Heinzi
  • 167,459
  • 57
  • 363
  • 519
  • funny how the Eric's blog didn't show up in my search results. (And it was in Eric's answer, facepalm) Thank you! – Lews Therin Jul 31 '18 at 15:09
  • 1
    This was exactly what I was thinking, but what about the paragraph that says "Also, doing it properly would require some changes to the CLR. Right now the CLR treats ref-returning methods as legal but unverifiable because we do not have a detector that detects this situation:"? – Camilo Terevinto Jul 31 '18 at 15:10
  • Another blog you might be interested in (that showed up in my searching): http://adamsitnik.com/ref-returns-and-ref-locals/ – Flydog57 Jul 31 '18 at 15:10
  • @CamiloTerevinto Good point, this sounds dangerous to me. Sounds like undefined behavior. It's worrying – Lews Therin Jul 31 '18 at 15:11
  • 2
    @CamiloTerevinto: It appears that they implemented this "detector" in the C# compiler: Trying to compile the "problematic" example code mentioned by Eric in his answer yields a compile-time error: *Cannot use a result of 'Program.M1(ref int)' in this context because it may expose variables referenced by parameter 'x' outside of their declaration scope.* – Heinzi Jul 31 '18 at 15:12
  • @Heinzi That sounds ok, but is there a possibility of undefined behaviour in older CLR versions? In other words, regarding `ref return` are there any specific code handling in .NET >4.6 that are *not* in previous .NET frameworks. But I can't find this... – Lews Therin Jul 31 '18 at 15:17
  • 1
    From the adamsitnik blog post I referenced: "But how is it possible that the new ref locals feature works with the legacy Jits? Have Microsoft released a Windows patch with .NET framework improvements? No! C# features like ref parameters, locals and returns are just using the existing feature of CLR called managed pointers. So to use it you just need IDE with Roslyn 2.0 version (Visual Studio 2017 or Rider) and you can deploy the code to your client’s old virtual machine which might be running with some very old .NET framework ;)" – Flydog57 Jul 31 '18 at 15:19
  • @Flydog57 OK, my worries are allayed for now. I will keep reading the blogs. Thanks :-) – Lews Therin Jul 31 '18 at 15:23
  • @LewsTherin: Undefined behavior in C# is very rare, see [this question](https://stackoverflow.com/q/1860615/87698) for some examples. Given C#'s "pit of success" design philosophy, I consider it *highly unlikely* that the C# compiler would allow you to compile `ref return` code targeting .NET 2.0 and deliberately create "undefined behaviour code" without so much as a warning. – Heinzi Jul 31 '18 at 15:28
  • @Heinzi That's very true! Thanks – Lews Therin Jul 31 '18 at 15:35