[Proposal] System.Void as a first-class type

[jbogard]

Today, you cannot use System.Void as a first-class type. That is, it is illegal in C# to do:

var foo = new Func<Void>(() => { });

This gives you the compiler error:

error CS0673: System.Void cannot be used from C# -- use typeof(void) to get the void type object

In other languages and frameworks, there exists the concept of the Unit type (F# and Rx). The lack of a true void type means duplication of delegates - Func and Action, and typically API duplication to handle things that return or things that don't return. This means overloaded types, duplicate methods, helper classes and more, even though the API itself does not care if the underlying delegates return values or not.

[aidapsibr]

I strongly back this proposal.

This becomes very prominent when working with async code as Task vs Task<TResult> require different code in user space as well as in compiler generated statemachines. Try using TTask where TTask : Task on an async method for instance.

[Logerfo]

Related #696 #135

[Joe4evr]

Also a literal duplicate of dotnet/roslyn#234.

[HaloFour]

There are numerous conversations here as to why Void can't be a good generic argument and why Unit and Void are not synonymous. I'm not opposed to the addition of the concept of Unit and language integration to better support it, but I don't think it's a good idea to conflate that idea with Void.

The duplicate delegate situation has been mentioned numerous times, but neither this proposal nor any of the other proposals could solve that. The IL of the method body has to be constant regardless of the generic type arguments, and that's not possible if the method alternately pushes or doesn't push a result onto the stack as the return value.

[aidapsibr]

I'm going to fall back to #696 for conversation.

[Unknown6656]

I'm just going to mention #1604 for completeness

[stakx]

If void were to become a first-class type (against which the CLI standard currently has rules, btw.) you would have to be able to declare a void variable. Do we really want to be able to do this? And what would that look like?

void arg = default; // or what does "the void value" look like?
Func<void> action = a => Console.WriteLine(a); // or would () be allowed for the parameter list?
action(arg); // or should the arg list be empty?

I agree that the delegate type duplication (Action vs. Func) can be annoying and cause code duplication. Introducing an empty System.Unitstruct would be mostly sufficient to mitigate this problem, and not require us to solve the above (and further) language design problems.

I believe .NET and the whole ecosystem has come much too far for this proposal to go through only now. I believe at this point, adding System.Unit to the BCL would be more reasonable.

PS: The "delegate duplicates" problem wouldn't be completely solved for library authors even if the Action/Func distinction were no longer necessary. there's still the problem of parameters being by-value, or any of the three by-ref variants, the latter of which aren't covered by Func. So I'm saying if redundant delegate types are the problem this is proposal is supposed to solve, then it's only a partial solution at best.

[jbogard]

That makes sense, System.Unit in netstandard2.1

…

On Mon, Jun 4, 2018 at 12:53 PM stakx ***@***.***> wrote: If void were to become a first-class type (against which the CLI standard currently has rules, btw.) you would have to be able to declare a void variable. Do we really want to be able to do this? And what would that look like? void arg = default; // or what does "the void value" look like?Func<void> action = a => Console.WriteLine(a); // or would () be allowed for the parameter list?action(arg); // or should the arg list be empty? I agree that the delegate type duplication (Action vs. Func) can be annoying and cause code duplication. Introducing an empty System.Unitstruct would be mostly sufficient to mitigate this problem, and not require us to solve the above (and further) language design problems. I believe .NET and the whole ecosystem has come much too far for this proposal to go through only now. I believe at this point, adding System.Unit to the BCL would be more reasonable. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/1603#issuecomment-394442298>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGYMmxMfD6umoL06SaJP2fbRXUOKsCiks5t5XQZgaJpZM4UZQK8> .

[AustinBryan]

In your example, why not just use Action instead of Func?

@stakx Well they could make it abstract, but then it couldn't be sealed, and we don't want any MyClass : void. They could make it static, but then it can't be used as a type parameter which is the problem trying to be solved in the first place.

[ufcpp]

There are too many overloads of Task.ContinueWith.

Task ContinueWith(Action<Task<TResult>>)
Task ContinueWith(Action<Task<TResult>>, CancellationToken)
Task ContinueWith(Action<Task<TResult>>, TaskScheduler)
Task ContinueWith(Action<Task<TResult>>, TaskContinuationOptions)
Task ContinueWith(Action<Task<TResult>>, CancellationToken, TaskContinuationOptions, TaskScheduler)
Task ContinueWith(Action<Task<TResult>,Object>, Object)
Task ContinueWith(Action<Task<TResult>,Object>, Object, CancellationToken)
Task ContinueWith(Action<Task<TResult>,Object>, Object, TaskScheduler)
Task ContinueWith(Action<Task<TResult>,Object>, Object, TaskContinuationOptions)
Task ContinueWith(Action<Task<TResult>,Object>, Object, CancellationToken, TaskContinuationOptions, TaskScheduler)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,TNewResult>)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,TNewResult>, CancellationToken)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,TNewResult>, TaskScheduler)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,TNewResult>, TaskContinuationOptions)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,TNewResult>, CancellationToken, TaskContinuationOptions, TaskScheduler)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,Object,TNewResult>, Object)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,Object,TNewResult>, Object, CancellationToken)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,Object,TNewResult>, Object, TaskScheduler)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,Object,TNewResult>, Object, TaskContinuationOptions)
Task<TNewResult> ContinueWith<TNewResult>(Func<Task<TResult>,Object,TNewResult>, Object, CancellationToken, TaskContinuationOptions, TaskScheduler)
Task ContinueWith(Action<Task>)
Task ContinueWith(Action<Task>, CancellationToken)
Task ContinueWith(Action<Task>, TaskScheduler)
Task ContinueWith(Action<Task>, TaskContinuationOptions)
Task ContinueWith(Action<Task>, CancellationToken, TaskContinuationOptions, TaskScheduler)
Task ContinueWith(Action<Task,Object>, Object)
Task ContinueWith(Action<Task,Object>, Object, CancellationToken)
Task ContinueWith(Action<Task,Object>, Object, TaskScheduler)
Task ContinueWith(Action<Task,Object>, Object, TaskContinuationOptions)
Task ContinueWith(Action<Task,Object>, Object, CancellationToken, TaskContinuationOptions, TaskScheduler)
Task<TResult> ContinueWith<TResult>(Func<Task,TResult>)
Task<TResult> ContinueWith<TResult>(Func<Task,TResult>, CancellationToken)
Task<TResult> ContinueWith<TResult>(Func<Task,TResult>, TaskScheduler)
Task<TResult> ContinueWith<TResult>(Func<Task,TResult>, TaskContinuationOptions)
Task<TResult> ContinueWith<TResult>(Func<Task,TResult>, CancellationToken, TaskContinuationOptions, TaskScheduler)
Task<TResult> ContinueWith<TResult>(Func<Task,Object,TResult>, Object)
Task<TResult> ContinueWith<TResult>(Func<Task,Object,TResult>, Object, CancellationToken)
Task<TResult> ContinueWith<TResult>(Func<Task,Object,TResult>, Object, TaskScheduler)
Task<TResult> ContinueWith<TResult>(Func<Task,Object,TResult>, Object, TaskContinuationOptions)
Task<TResult> ContinueWith<TResult>(Func<Task,Object,TResult>, Object, CancellationToken, TaskContinuationOptions, TaskScheduler)

If we have a unit type, only quarter of these are needed. We can replace Func<Task,TNewResult>, Action<Task<TResult>>, and Action<Task> by Func<Task<TResult>,TNewResult>.

[stakx]

If we have a unit type, only quarter of these are needed.

Totally agree that reducing redundancy would be nice, but what are you going to do about all the existing code that has been compiled against the redundant overloads? Is removing any overloads at this point feasible?

[ufcpp]

I often write similar codes, especially extension methods to Task and Task<T> . I really want to avoid it, This is feasible for my own codes while it is not for existing Tasks overloads.

[AustinBryan]

So what would be the benefit of using Func<void> versus Action?

[aidapsibr]

@AustinBryan

The benefit is to designers, and some edge cases where your code has to slightly change to handle returns vs no return, when otherwise the code could have been shared.

In an API you could then have a single overload instead of two, one for action and one for Func of TResult, instead you just one for Func of TResult.

[ufcpp]

and what is worse, the number of overloads are exponential.

static class TaskTupleExtensions
{
    //  combination of 2 tasks = 4
    public static TaskAwaiter GetAwaiter<T1, T2>((Task<T1>, Task<T2>) t) ...;
    public static TaskAwaiter GetAwaiter<T1>((Task<T1>, Task) t) ...;
    public static TaskAwaiter GetAwaiter<T2>((Task, Task<T2>) t) ...;
    public static TaskAwaiter GetAwaiter((Task, Task) t) ...;

    //  combination of 3 tasks = 8
    public static TaskAwaiter GetAwaiter<T1, T2, T3>((Task<T1>, Task<T2>, Task<T3>) t) ...;
    public static TaskAwaiter GetAwaiter<T1, T2>((Task<T1>, Task<T2>, Task) t) ...;
    public static TaskAwaiter GetAwaiter<T1, T3>((Task<T1>, Task, Task<T3>) t) ...;
    public static TaskAwaiter GetAwaiter<T2, T3>((Task, Task<T2>, Task<T3>) t) ...;
    public static TaskAwaiter GetAwaiter<T1>((Task<T1>, Task, Task) t) ...;
    public static TaskAwaiter GetAwaiter<T2>((Task, Task<T2>, Task) t) ...;
    public static TaskAwaiter GetAwaiter<T3>((Task, Task, Task<T3>) t) ...;
    public static TaskAwaiter GetAwaiter((Task, Task, Task) t) ...;

    //  combination of n tasks = 2^n
}

[AustinBryan]

@psibernetic Okay, that was my guess.

@ufcpp What would that code look like with void or unit?

[jnm2]

@ufcpp But since Task<> derives from Task, why would you ever mix the two in a GetAwaiter signature?

It's not like there's a reasonable way to get a tuple-resulting awaiter back out as a result (since we don't have unit 😄), so you're just getting void-resulting awaiter and therefore don't need to know the generic types of any of the passed Task instances.

[ufcpp]

@JMN2

This is just simpified version. To get results, full version is:

    public static TupleTaskAwaiter<T1, T2> GetAwaiter<T1, T2>((Task<T1>, Task<T2>) t) ...;
    public static TupleTask1Awaiter<T1> GetAwaiter<T1>((Task<T1>, Task) t) ...;
    public static TupleTask2Awaiter<T2> GetAwaiter<T2>((Task, Task<T2>) t) ...;
    public static TupleTaskAwaiter GetAwaiter((Task, Task) t) ...;

[jnm2]

These I disagree with:

    public static TupleTask1Awaiter<T1> GetAwaiter<T1>((Task<T1>, Task) t) ...;
    public static TupleTask2Awaiter<T2> GetAwaiter<T2>((Task, Task<T2>) t) ...;

I don't think you should be getting a result if any of the things in the tuple has no result.

[Thaina]

#380 #1454