Allow return void function with void function

[Thaina]

In some condition we would do short logic and return from function immediately

So I think we should allow to return from void function with another void

void LoadAndDoSomething(string url)
{
    var obj = Load(url);
    if(obj == null)
        return Console.WriteLine("Not found " + url);

    // Do Something
}

Should also work with Task

async Task LoadAndDoSomethingAsync(string url)
{
    var obj = await LoadAsync(url);
    if(obj == null)
        return Console.WriteLine("Not found " + url);

    // Do Something
}

There are suggestion that we should be able to explicit cast (void) to be able to return function with any return type

void LoadAndDoSomething(string url)
{
    var obj = await LoadAsync(url);
    if(obj == null)
        return (void)Debug.Log("Not found " + url); // This Debug.Log return int

    // Do Something
}

This was ported from dotnet/roslyn#11330

Alternative

guard statement #138
I was propose it should use return if syntax. Which would be more generalize

if(condition)
    return DoSomething()

/// equivalence to
return if(condition)
    DoSomething();

[lachbaer]

I think it looks confusing, because it looks as if I am really returning something.
Currently you would write it like

void LoadAndDoSomething(string url)
{
    var obj = Load(url);
    if(obj == null)
        { Console.WriteLine("Not found " + url); return; }

    // Do Something
}

though putting the return on a single line would be better, because you should always mark the places good visible when returning before the end of a function.

[Thaina]

{ Console.WriteLine("Not found " + url); return; }

This hack is so dirty. Too dirty. And will be gone with auto formatting

While in any other return type function except void we could return function that has same return type

int CountOrSingle(IEnumerable<int> ints)
{
    int i = Load(url);
    if(ints.Count() > 1)
        return ints.Count();

    return ints.Single();
}

To not allow return void actually make inconsistent syntax

[lachbaer]

@Thaina
Yes it is dirty 😈 😄
But when you return from a called function you actually do return something.

return ints.Count() says me literally that I return and that I return the result of ints.Count().
In case of a Console.WriteLine() 'like a mixed up language to me it is' 😉
Because actually I

• first 'Console.Writeline()'
• and then 'return'

That's why we should write it in two lines.

[Thaina]

Yes, I return void
void is something. It is return type. So return void is returning the return type

[bbarry]

I'd like to be able to use System.Void for things (specifically for delegates, expressions and tasks and potentially to be able to return default(void)) but I don't think it would be good to have conversions to void.

edit:

Right now there is an annoying quirk that you need to double your api size to support the dichotomy of generic things that return values and ones that don't.

[lachbaer]

In my understanding of the word 'void' it is not kind of a type void, but also an expression of not being applicable, being even 'less than nothing' (with nothing being at least something 😉 ).
So you do not return a void, you not even return void because any return would be voided. So void is not a type, it is kind of a modifier. At least that's my point of view - others allowed

(Oxford Dictionaries)

[fanoI]

Well it is a type in .Net "System.Void" but it is not exposed to high level languages!

[louthy]

void in type theory is a type that can have 0 values (like bool can have two: true, false). So a type that can't have a value, can't be instantiated, and therefore can't be 'returned'.

Instead of a new language feature, just use a type that can have exactly 1 possible value: namely unit.

I have an implementation here

But at its simplest:

    public struct Unit : IEquatable<Unit>
    {
        public static readonly Unit Default = new Unit();

        public override int GetHashCode() => 0;
        public override bool Equals(object obj) => obj is Unit;
        public override string ToString() =>"()";
        public bool Equals(Unit other) => true;
        public static bool operator ==(Unit lhs, Unit rhs) => true;
        public static bool operator !=(Unit lhs, Unit rhs) => false;
    }

Also if you define a static field like so:

 public static class Prelude
 {
    public readonly static Unit unit => Unit.Default;
 }

And include the containing class:

    using static Prelude;

Then you can do stuff like this:

    public Unit Foo()
    {
        // ... Do something ...
        return unit;
    }

Which makes the method usable in plenty of places where a return type is needed (LINQ expressions, Func<...,R> etc.)

[Thaina]

@lachbaer Well , in my understanding, void is nothing. And that's it, nothing is a thing and we can return nothing. It abstraction like we return NaN for float. We just want to say it nothing and always nothingness

void of space is common wording

But anyway. I don't think we need that much philosophy. I just think it useful to keep code compact and being one line

Also in lambda expression. It can assume that you return void when you call void function in lambda. By this assumption I think anywhere should be the same

I mean

int X() { return 0; }
void A() { }

Func<int> action = () =>X(); // lambda can guess that you return int from int function, so this is int function
Action action = () =>A(); // lambda can guess that you return void from void function, so this is void function

[louthy]

in my understanding, ... nothing is a thing

'no thing' is not a thing. Your understanding is wrong I'm afraid.

[Thaina]

@louthy What you said is like 0 is not a thing. Space is not a thing

You are not wrong. We have zero things means we don't even have a thing.

But I think it's all about context. We have zero as number. We has spacebar and space character to make space. And we have void of space to define volume that really have nothing

But is empty volume is a thing?

As someone already pointed out. We even have System.Void which is really something in context of C#

Programming make use of abstraction and we make abstraction of void mean a thing in programming. So we can have void as return type. Why we can have return type be void but cannot return void?

I think we actually always return void

[louthy]

0 as an integer doesn't mean 'no integer' though, it's one of the valid set of integers. Which is the same as the space character, it's still a valid character, with a real representation (0x20). But a type that has no representative values can't be instantiated. That's why void can't be returned, and that's why a unit-type is better:

Take a look at Core Computational Type Theory

void is a type with no elements
unit is a type with one element

Personally I would love to see all uses of void in the BCL be replaced with Unit, because it would make working with expressions much simpler. But I can't back the change of meaning of void.

[Thaina]

@louthy I don't think you need to change any meaning of void it just that, nothing in one context is being something in another context

Like you said, in context of programming 0 is number. But in context of natural number. 0 is not a number. Even negative is not natural number. So as space that in writing it is nothing. Just an empty gap between word. But in context of computer it must have value 0x20

So would you choose to have void being a thing in context of coding or not?
I think we have System.Void is already a proof of being thingness in C#

In some language like js there are concept of undefined that you will get if you return void. Is undefined a thing?
At least undefined and void is information. Information that tell us about no information. Like 0 tell us that there are no natural number

[lachbaer]

Boy (girl), what a disussion... 😜

I think the discussion should just be about whether we can treat void as a valid return type.

I myself have a discussion on dotnet/roslyn#9834 about allowing the void keyword as parameter for methods and lambdas to make the code a bit more verbose in places where otherwise would be only a bunch of non-alphanumeric characters

void AMethod(void) { }
var t = Task.Run( (void) => { /* ... */ } );

The last line currently being

var t = Task.Run( () => { /* ... */ } );

So ( () => { all being slender characters. But I digress, that's out of scope in this discussion.

On a logical side I totally see what @Thaina wants to achieve.
But just by looking at something like

  return Console.WriteLine("We are leaving the procedure now");

my stomach turns 😧 It's just my guts...

[Thaina]

@lachbaer Well... I just don't felt anything because that is valid in some other language like C++ and js

http://stackoverflow.com/questions/3383090/is-returning-void-valid-code

[kind-serge]

Folks, let's look at the problem from another perspective. You can define your own Void type like this:

    [StructLayout(LayoutKind.Sequential, Size = 0)]
    public struct Void { }

Now you are allowed to use this type anywhere you want - you can return it as a result of a function, you can use it as a generic parameter. What it means to use such type is a different question, but you are allowed to do so, and the runtime does not break.

System.Void and your own Void are semantically equal, they are just 2 different types. Should zero-length value types be not allowed then, because it breaks the non-unit type philosophy?

Please see another proposal where relaxing rules on Void might be useful:
Proposal: Allow Void type as a Generic parameter.

---

P.S. the System.Void type is defined like this in mscorlib 4.0.0.0:

namespace System
{
	/// <summary>Specifies a return value type for a method that does not return a value.</summary>
	/// <filterpriority>2</filterpriority>
	[__DynamicallyInvokable, ComVisible(true)]
	[Serializable]
	[StructLayout(LayoutKind.Sequential, Size = 1)]
	public struct Void { }
}

So it's either a bug in the definition, or System.Void is actually a disguised unit type.

[Akronae]

Why not something like:

if (credentials.Code == Codes.BadCredentials) vreturn Console.WriteLine("Bad Credentials !');

instead of:

if (credentials.Code == Codes.BadCredentials)
{
    Console.WriteLine("Bad Credentials");
    return;
}

vreturn could be a keyword that says "return void".

There are plenty of cases where this keyword would improve code readability & maintenance 👍

[lachbaer]

@Akronae I'd prefer void return over vreturn, because then there was no need for an additional keyword. And it's not worse than yield return. To me the question is rather whether returning void itself could be a valid C# construct in the sense of the language. I would go with yes as long as type safety is guaranteed, meaning that there must exist any kind of void casting to value returning functions.

[Akronae]

So we might go with something like return Console.WriteLine as void ?

[Thaina]

@Akronae Console.WriteLine("") is already void

[Akronae]

I know but it could be a way to implicitly tell the compiler "I want you to return void" and if the conversation fail (null) then the compiler throw an error.

[Thaina]

@Akronae conversion from null to void is not an error. returning void is not really return anything. Just return from current stack to upper stack, same as return;

There are mention about conversion because some function can return state as result, and it should be casted to void

This proposal just propose syntactic sugar for one line returning but not changing any behaviour

[Joe4evr]

"I want you to return void" and if the conversation fail (null) then the compiler throw an error.

Your supposed syntax would not even be legal outside of a void (or async Task) method in the first place.

Quoting myself from a related thread:

The main take-away from this and the related issues is the fact that people desire a standard, Microsoft-supported implementation of Unit.

Let's stop trying to "enhance" void and create a better solution instead.

[Thaina]

@Joe4evr We don't really want Unit type to do anything and it not backward compatible with all of the void function we already have in BCL or any C# library in the world

Your Unit cannot make me able to return Console.WriteLine(""); when I need to return it inside if clause because no one ever write Console.WriteLine("") to return Unit

[MBeran]

Hi, the return Console.WriteLine(""); looks very weird.
I came here for

async Task SomeMiddlewareInvoke()
{
    /* ... */

    if (somethingWentWrong)
        return CleanUpAndTerminate();

    /* ... */
}

Task CleanUpAndTerminate()
{
    /* ... */
}

instead of

async Task SomeMiddlewareInvoke()
{
    /* ... */

    if (somethingWentWrong)
    {
        await CleanUpAndTerminate();
        return;
    }

    /* ... */
}

[jnm2]

@MBeran To me, not-really-returning a Task instance seems just as weird as not-really-returning void. You can't think of this as actually returning the Task instance returned by CleanUpAndTerminate.

[Suamere]

I'd like to point out that we can now return void in C#, but only in a limited fashion. But given that the step was taken in that direction, I believe there are grounds to make it a full feature.

private string GetValue(int someValue) => someValue.ToString();
private void WriteToConsole(string val) => Console.WriteLine(val);

I realize there is some syntactic sugar there. But if that's the argument, then just make syntactic sugar work for this:

private async Task LogAndReturn(string val) {
    var logVal = string.Format("{0}, lol", val);
    await Log.DoStuff(logVal);
}

private async Task<T> LogAndReturn<T>(string val, T value) {
    var logVal = string.Format("{0}, lol", val);
    await Log.DoStuff(logVal);
    return returnValue;
}

public async Task ExecuteTaskLol(parameters . . .) {
    if (SomeValidation(param1) == false)
        return await LogAndReturn(param1); // <-- This should work vvvv

    DoMoarExecute(parameters . . .);
}

public async Task<bool> ExecuteTypedLol(parameters . . .) {
    if (SomeValidation(param1) == false)
        return await LogAndReturn(param1, false); // <-- The same as this ^^^

    DoMoarExecute(parameters . . .);
}

And though that example is async, it should also work just as well without async:

private void LogAndReturn(string val) {
    var logVal = string.Format("{0}, lol", val);
    Log.DoStuff(logVal);
}

private T LogAndReturn<T>(string val, T value) {
    var logVal = string.Format("{0}, lol", val);
    Log.DoStuff(logVal);
    return returnValue;
}

public void ExecuteTaskLol(parameters . . .) {
    if (SomeValidation(param1) == false)
        return LogAndReturn(param1); // <-- This should work vvvv

    DoMoarExecute(parameters . . .);
}

public boolExecuteTypedLol(parameters . . .) {
    if (SomeValidation(param1) == false)
        return LogAndReturn(param1, false); // <-- The same as this ^^^

    DoMoarExecute(parameters . . .);
}

[Korporal]

I see no benefit to this.

The reality is that void as a return type is itself misleading, but the original C grammar expressed procedures that way and that's been passed down to the various derived grammars ever since.

Also the examples you give imply the return happens followed by some operation, before the code actually finishes, that's just so confusing.

If nothing is being returned the grammar should not pretend or imply that something is being returned.

So I'd leave this well alone, it is what it is.

[siegfriedpammer]

I agree, the only thing that should ever be done if the LDM decides to touch void is turning it into a valid type for generic type arguments. So that Task can simply be written as Task<void> and Action<...> as Func<..., void> just as Java allows.

But that seems to be a major breaking change in the CLR/CLI so we will probably never see this happen.

[GabeSchaffer]

What would that break? Right now it's invalid to use void as a type argument, so there's obviously no existing code that would change behavior or fail to compile as a result.

[siegfriedpammer]

I was not talking about C#. I was talking about the Common Language Infrastructure, which the CLR (Common Language Runtime aka .NET runtime) and its type system are part of.

If you are interested in such topics, I can suggest reading the ECMA-335 specification.

Currently, there are some differences in the IL (yes, C# gets compiled to an intermediate language) for void returning methods and how they are handled in the runtime. Void is not a real type currently.

The internal format of type specifications/signatures would have to be extended to support void, for example. (This would not break existing applications, but tools that work on the internal format, like development tools.)

Changing all that would probably be a breaking change, causing problems with existing compiled applications running on the new version.

These are just examples and someone from the .NET team might be able to provide more insight.

[CyrusNajmabadi]

I still see no problem with this. My preference is that it be taken further (like I mentioned with switch Expressions). Having void be more like a unit type that can flow naturally seems sensible.

Low priority on this though.

[siegfriedpammer]

Would your plans include the use of void as type arguments? Or has that ship sailed?

[CyrusNajmabadi]

if the runtime allows it, sure. The discussion here though wouldn't need that. It would simply be a case of the lang refining return to allow a void expression, and that being fine in a void-returning-method context.

[prostolyubo]

If this is so controversial, how about adding a new keyword?

void LoadAndDoSomething(string url)
{
    var obj = Load(url);
    if(obj == null)
        returnafter Console.WriteLine("Not found " + url);

    // Do Something
}

This has added benefit of being able to use methods that actually return something. Because if you would call:

void LoadAndDoSomething(string url)
{
    var obj = Load(url);
    if(obj == null)
        return url.ToString();

    // Do Something
}

I would expect compiler to give me an exception if a valid cast does not exist since you are trying to return a string as a void. But with:

void LoadAndDoSomething(string url)
{
    var obj = Load(url);
    if(obj == null)
        returnafter url.ToString();

    // Do Something
}

you don't imply you intend to return anything.

Seems hacky, and adding an additional keyword just to handle some edge case seems a bit much. Nonetheless I'm just curious what you think.