Feature Request: Implicit/Implied Return Object

[lennycode]

If you need to return an object that requires processing, you are forced to declare an object, same as 1980s C++:

public List<List<String>> GetFilesInBuckets()
       {
           List<List<String>>  FileBucket = new List<List<String>>();
           Directory.EnumerateDirectories(bfolderPath).ToList().ForEach(s =>
           {
               FileBucket.Add(Directory.EnumerateFiles(s, "*.exe").ToList());
           });
           return FileBucket;
       }

I wonder if something like this could be implemented:

public List<List<String>> GetFilesInBuckets()
       {
           Directory.EnumerateDirectories(bfolderPath).ToList().ForEach(s =>
           {
               __.Add(Directory.EnumerateFiles(s, "*.exe").ToList());
           });
           return __;
       }

I often deal with complex, nested dictionary return types and it is just extra lines of boilerplate code to maintain. Sometimes the return type changes, and there is more code to fix. I know there is Deconstruct and Throwaways - this would seem like a nice addition to that. Throwaway is a single underscore, implied return object is a double. A declared double underscore in the sub would override this feature.

In a perfect world, in this use case return could go away too 😁

[HaloFour]

Even in languages that support something like this your example would fail as the default value of a List<T> is null. Unless you're suggesting that the compiler automatically allocates an instance? That would be a massive perf regression. And it would make zero sense for types that have no public parameterless constructors.

With var and target-typed new so much of this "boilerplate" goes away.

[svick]

Is there a reason why your code isn't written like this?

public List<List<String>> GetFilesInBuckets()
{
    return Directory.EnumerateDirectories(bfolderPath)
        .Select(s => Directory.EnumerateFiles(s, "*.exe").ToList()).ToList();
}

[lennycode]

@HaloFour
I use var but it is still extra code.

I agree now, Probably isn't the best idea.

Was thinking of a simple substitution type instance for a default constructor object, but I don't know what goes on behind the scenes.

I had hundreds of those type methods in a project, some would change a bit and I would have to edit the code, so I guess it would be a specific case.

@svick
That is they way they want the code to stay :(

[lennycode]

@svick
Also, much of the code also has many lines of initialization before that statement, so I'm forced to declare.
What if the syntax changed to

__(constructorparams){Optional}

Just trying to avoid having the type if it is implied in the return. Probably still not such a good idea.

[bondsbw]

It is very unlikely that a language feature is considered when the main use case boils down to "we want to work around our code guidelines".

[avin-kavish]

I was reading this and felt like I had to leave this for future readers

public List<List<String>> GetFilesInBuckets() => 
        Directory.EnumerateDirectories(bfolderPath)
        .Select(s => Directory.EnumerateFiles(s, "*.exe").ToList()).ToList();

C# 6+ This is one statement.
Expression Bodies, FTW