[Proposal] returntype as keyword for return type

[mhomde]

Apologies if something like this has already been discussed.

For nearly twenty years I've been writing code like:

public SomeClass DoStuff()
{
   SomeClass result;

    ... do stuff

   return result;
}

Having to put "SomeClass", which can be a complex generic type, in two places.

Even if I use var:

public SomeClass DoStuff()
{
    var result = new SomeClass();

    ... do stuff

  return result;
}

Now if change the return type of the class I also have to change it in two places, and if there's an interface or inherited class there's a chance it will be overlooked.

Would it be a good idea to have keyword similar to default, but for return type? Then I could do:

public SomeClass DoStuff()
{
    returntype result;

    ... do stuff

   return result;
}

and even:

public SomeClass DoStuff()
{
    var result = new returntype();

    ... do stuff

  return result;
}

It's a little thing but I think it'd could:

• Reduce redundancy.
• Reduce tedium.
• Declare intent of a variable being of return type.
• Refactoring return type will in many cases need no additional edits.
• Make copy & paste easier.

You'd get a compiler error if the constructor doesn't match. Would also work for Properties, Indexers etc.

[HaloFour]

I don't see var result = new returntype(); being an improvement over var result = new SomeClass();. In many cases it would even be more verbose, or couldn't be used at all due to the return type being a non-instantiatable type like an interface.

[mhomde]

I don't see var result = new returntype(); being an improvement over var result = new SomeClass();. In many cases it would even be more verbose, or couldn't be used at all due to the return type being a non-instantiatable type like an interface.

Well that's true, but you wouldn't have to change it in two places. And if you get compiler error you're violating the intent of the method author and will take a second look. Prevent's error prone edits overlooking the instantiation when changing the return type.

Also returntype could perhaps more easily be autocompleted by Intellisense.

[HaloFour]

Prevent's error prone edits overlooking the instantiation when changing the return type.

IMO if you're changing the return type you should probably be reviewing your instantiation. I'd much rather a compiler error that forces the issue than syntax candy that hides a potentially difficult to notice logic error.

[DaZombieKiller]

An alternative would be to allow var as a return type (which the compiler would resolve similarly to how an expression-based switch gets its type). However that still has numerous issues:

• Brittle due to how easily it can change.
• You can't just glance at the signature to know the return type.
• Your API surface is less clearly defined.

...etc, to the point where I wouldn't really want that either.

Ultimately, what I'd prefer would be local aliases (using T1 = T2;), so you could do something like this:

using RDoStuff = SomeClass;
public RDoStuff DoStuff()
{
    RDoStuff result;
    // do stuff
    return result;
}

EDIT: An extension upon this could be:

public SomeClass DoStuff()
{
    // In the context of an alias within a function, 'return' refers to the function return type.
    using returntype = return;
    returntype result;
    // do stuff
    return result;
}

Obviously since the example given only uses the type once this seems to complicate the code rather than simplify it, but I can imagine it improving things where the type is used much more. There's also the issue of differentiating this from a using statement (and also considering 'Interactive C#', where I imagine using becomes a more complicated subject).

[franchyd]

Just type the class name twice. Language Design's goal isn't minimal character code. Sometimes you need to be explicit to make the code understandable. I don't want to have to rewind all the way to the method definition to determine what type is being instantiated when reading code.

[mhomde]

Just type the class name twice. Language Design's goal isn't minimal character code. Sometimes you need to be explicit to make the code understandable. I don't want to have to rewind all the way to the method definition to determine what type is being instantiated when reading code.

Well we can all discuss the goals of Language design :)

While I agree we shouldn't minimize code written ad absurdum... efficiency, reducing repetition and declaring intent are all good design goals. In real-life enterprise projects, time costs money, lines costs overhead. There's a reason why we have some "syntactic sugar" in the language, such as null-coalescing, var, default etc etc.

Result variables should IMHO optimally be declared as the very first line of your method, so I don't really understand the "rewind" problem.

Then again I also think every method should end with just one return statement (rather than peppering them throughout the code) for clarity, but that might be just me :)

Whereas the potential misuse, it's a tool like everything else and should be used judiciously.

[CyrusNajmabadi]

@mhomde these are stylistic preferences on your part. You can add such rules simply by writing your own analyzers if you want that sort of format. It's not something the language is going to mandate for the community and ecosystem as a whole.

[mhomde]

@mhomde these are stylistic preferences on your part. You can add such rules simply by writing your own analyzers if you want that sort of format. It's not something the language is going to mandate for the community and ecosystem as a whole.

Indeed. I'm not mandating anything :) Use is completely optional.

[CyrusNajmabadi]

That wasn't my point :) My point is that you don't need any language features for the specific things i was responding to. It can be done with analyzers. :)

[Vlad-Stryapko]

I don't think it's a useful feature to have. The only scenario when it works is when you have return types such that the rest of the code works with either of them without any changes. Otherwise, you still have to go and update the actual instantiation or the usage of the instance. I'd say that such scenario is pretty rare, at least in my experience of working with .NET (and Java).

[Orace]

In your example:

public SomeClass DoStuff()
{
  var result = new SomeClass();
  //    ... do stuff
  return result;
}

If SomeClass is complex and long, you want to write it as less as possible.
You don't want to write it as return type nor as instantiation.

using alias directives addresses this :

using Easy = SomeClass; // And you are free to change the "alias-ed" class

public Easy DoStuff()
{
  var result = new Easy();
  //    ... do stuff
  return result;
}

It's work fine until you do some generic code.
That's sad because in generic code, you often wish to be able to reduce class names.

I opened #2981 that addresses this.
With this proposal, you may write:

// using alias example
class MyClass<TBar, TFoo>
    using FooByBar = System.Collections.Generic.Dictionary<TBar, TFoo>;
{
  public FooByBar DoStuff()
  {
    FooByBar result = _cache ?? new FooByBar();
//    ... do stuff
    return result;
  }
}