CyrusNajmabadi

Sure. Write a Roslyn analyzer to help out here.

Note: it's not like you can just sprinkle 'ref' on the return type of your methods willy nilly. Like 'ref'/'out' parameters, it requires you to do very specific things to keep your code safe/legal. As such, it's unlikely to just be added by people because, by and large, most code won't be equipped to actually handle it properly.

The codebases that will want to use this are already ones that have done a lot of work that makes them amenable to ref. i.e. game engines where you have large arrays of structs that you want to operate on in an efficient manner and whatnot.

Hi David, language designer here.

Can you give an example of where you'd want to take advantage of this in C#?

Thanks!

Hi there! C# language designer here.

You can see (and participate in) the discussion on records here if you'd like: https://github.com/dotnet/roslyn/issues/10154

> Seems like it'd be a cinch to implement

Ah... how i wish that were so :)

Hi there, C# language designer here.

I don't really see your example in that way. Let's start with the latter one first:

> bar(out *); // oops, not I; was up too late coding

I'm not sure how this situation is any differnet from any other case where you need to pass some variable, and you pass the incorrect name. This is already possible all over the language. For example, you might have written "bar(out J)" when you meant "bar(out I)". As usual, the recommendations here are to use strong types and good names to help keep your code clear in intent and to allow the compiler to tell you when something seems awry.

Now let's look at your first example:

> foo(out int mvar);

This version immmediately screams at me that something is happening that requires my attention. First off, just the presence of 'out' is an immediate call that this is not a normal call. Nearly all calls pass by value, so out/ref stick out like a sore thumb (esp. in an IDE that classifies them accordingly). Second, the "out int" is another large indicator that this is doing stuff very special.

Finally, i'd point out that the mispelled name problem is really no different than what you might experience today with code like:

  int myvar;
  ...
  // much later and indented a bit ...
         int mvar;
         Foo (out mvar);

Here you've unintentionally introduced a new variable that you may or may not have intended to. Without a collision, there's no way to tell.

> it's this sort of bug that arises often in languages that allow implicit declaration of variants.

No implicit declarations are allowed. All declarations are explicit. We just don't force you to have to declare in one location and use in another. This is a pattern that many people hate, and which goes against a desire to immediately declare and initialize, and thus not have to track down how a variable is written to.

Hey there, C# language designer here.

> Out variables seem like a mis-feature, especially when they are adding a better alternative (Tuples) in the same release.

Out variables are really great when working with existing code that predates Tuples (for example, the entire BCL). We don't just introduce language features that will only work well for new code. We also want to make the experience of coding against existing APIs feel better.

> Ref returns and locals look like a source of constant headaches.

That 'headache' has to be weighed against the needs of some parties to write very fast code and to have as little overhead as possible. ref returns enables a much more pleasant coding experience that enables these sorts of speedups in these specialized scenarios.

> It's much harder to reason with code when the data can be modified by random others bits of code.

There is a simple solution to this of course, don't expose your data through ref returns :)

For many (likely most) developers, ref returns simply won't be something that ever hits their radar. Similar to stackallocs and other esoteric features, this is really a targeted improvement for people who really like working in .Net but are finding it hard to squeeze out essential perf in some core scenarios.

The .net runtime supports this features fantastically. We wanted to make it available to people who like the power and safety of C#, but occasionally need some low level hooks to get that extra perf boost as well.