Proposal: Add unit alias for System.ValueTuple

[OnurGumus]

As C# progressing towards being functional, we really need some sort of unit type. And many libraries invent their own unit type that returns nothing causing incompatibilities. System.ValueTyple with zero items is a very good candidate for being a unit type so I use it. I believe it is a good idea to have it aliased as unit. The drawback of this approach is that introducing a new keyword might conflict with existing code. But that can be solved by language versioning anyway.

[Joe4evr]

#883, #696

[stuartstein777]

I also use the System.ValueTuple with zero items aliased as a Unit and would like to see this baked into the language.

[Opiumtm]

Well... C# definitely needs official "Unit" type which would be allowed to be used as generic type argument.

In the ideal world compiler (and probably CLR) should "know" this official unit type and allow type compatibility between "unit" and "void". So, Func<unit> could be compatible and interchangeable with Action, method with unit return type could be assignable to Action delegate and method with void return could be assignable to Func<unit>, variable of type Func<unit> could be assignable to Action and so on.

Such void/unit type compatibility is required to avoid a major rewrite of already existent code base which is practically impossible.

Under the hood, unit could be a simple well-known empty struct with no fields (so having exactly zero bytes size).

C# also shouldn't require explicit return value from function if function result type is unit for obvious reason.

Ideally, CLR should recognize well-known unit struct and allow to use unit everywhere as a substitution for void and void everywhere as a substitution of unit. Without CLR support, C# compiler could just silently emit some "glue code" to allow such substitution. However, "glue code" would raise subtle issues as generated "glue" method to substitute for "compatible" delegate would have a different address than original method.

For my opinion, C-like void implementation is a major error in CLR and C# architecture. Any empty zero-sized struct is a semantic equivalent of void, so void wasn't even needed to exist in CLR and C# in the first place.

void pseudo-type was introduced just because of "C language family" legacy of C#. But even if void keyword is habitual for programmers with C/C++/Java background, void instead could be implemented as a well-known zero-sized empty struct under the hood without any "special" CLR treatment for it. JIT could easily detect a zero-sized empty struct as a return type and optimize generated native code just to not return anything from the method and do not expect anything to return from it. Probably JIT already optimizes native code generation in such a way as there is nothing to copy for value type which doesn't have any fields.

[HaloFour]

@Opiumtm

Any empty zero-sized struct is a semantic equivalent of void

There's no such thing as a zero-sized struct in the CLR. A struct with no fields is still a byte wide. at a minimum. And even if there was it's not semantically equivalent. A unit is still a value, void is the lack of the possibility of a value. The IL for the two must be different.

void pseudo-type was introduced just because of "C language family" legacy of C#.

The name, maybe. But nearly all imperative non-functional languages have the concept of void. This isn't some legacy baggage, it's just a different paradigm.

[alrz]

@HaloFour

Is System.Void a special type for CLR? in other words, can we have a C<Void> outside C#? if so, what's the reason to use another struct? On the bright side we can have syntactic candy in the compiler to make it seamless in case of type substitution.

interface I<T> { T M(); }
class C : I<void> {
  public void M() {
    // compiler generates code to return default(Void) under the hood.
  }
}

[orthoxerox]

@alrz It is, see https://github.com/dotnet/coreclr/blob/32f0f9721afb584b4a14d69135bea7ddc129f755/tests/src/JIT/Regression/CLR-x86-JIT/V2.0-Beta2/b353858/b353858.il

[alrz]

Ok. thanks. But still nothing stops you to emit whatever type instead of Void there.

I think that having to write unit M() { return (); } is not ideal IMO. We could make it look like a void-returning method and not require return statement anywhere in that method, the compiler could figure it out and generate appropriate code, no?

[Opiumtm]

@HaloFour

And even if there was it's not semantically equivalent.

Practically they're semantically equivalent. unit does have only one possible "value". Semantically a single possible value is equivalent to no value as single possible value contains exactly zero bits of information. To have at least one bit of information, the type should have at least two possible values. So, "no value" and "single possible value" does contain an equivalent amount of information - exactly zero bits.

When you say about unit as still a value, you base your opinion on technical implementation, not on amount of actual meaningful information in it.

But nearly all imperative non-functional languages have the concept of void

Imperative languages do use void in the same meaning as unit is used in functional languages. Functional languages require functions to always have "something" as a result, but every "something" with only a single possible value does contain same amount of information as "nothing" - no information at all, zero bits. unit is just a stub type which pretends to be "something" (in reality it's full equivalent of "nothing") in a context when "something" is strictly required. So such a zero-information fake is used to fulfill a requirement for "something", no more.

Foremost issue with void and its implementation in CLR is inability to use void as a generic type parameter and as an argument of method. It became most annoying when async/await was introduced and so distinct types Task and Task<T> was introduced. You can't just declare Task<void> and should resort to some form of homebrew unit struct to develop generic asynchronous algorithms. Another annoying example is when you develop generic wrapper functions which accepts delegate as a parameter and do some standard additional work (logging, for example) before and/or after delegate invocation. You should support both Func and Action here. When return value is just pass-through and isn't used inside a wrapper funciton which only introduces side-effects (logging, for example), inability to use void as a generic parameter is a major source of boilerplate code.

Technical implementation at CLR level how to internally treat void as generic argument or argument of method may be any.

You can argue that if void was a regular type then classes and structs could have a void as a type of field or property and it's an absurd. But I can argue that having a field of unit type (and of any struct with no fields and no additional methods) is no less an absurd and it's allowed by CLR.

[HaloFour]

@Opiumtm

I think that you've done pretty well to describe the paradigmic difference between void and unit and why they are incompatible. As you mentioned, functional languages require you to return something, even if it's nothing. Imperative languages don't, and when they don't, there isn't a place to put either something or nothing.

That's the difference. With unit you're putting nothing in the slot. With void, there is no slot.

That's not to say that I'm opposed to the notion of adding unit to the CLR or to the language. But I think that there's a big gap between void and unit from a functionality standpoint which would represent non-trivial work to bridge for ultimately limited gain.

[Opiumtm]

@HaloFour
There is no difference between unit and void beyond technical implementation details indeed.
Semantically both unit and void means "nothing" in regard to actual amount of passed (actually not passed, as "to pass nothing" is logically equivalent "to not pass anything") information. unit and void are different points of view on the exactly same thing.

[HaloFour]

@Opiumtm

Those implementation details matter. There are IL opcodes representing the slots of where to put stuff and how to move it around. They must be there for generic methods. For void there are no such things.

This is something that a functional language compiler can gloss over. But the CLR wasn't designed specifically for functional languages, and functional languages only make up a minority of the languages and audience that target the CLR.

[Opiumtm]

@HaloFour

Those implementation details matter. There are IL opcodes representing the slots of where to put stuff and how to move it around. They must be there for generic methods. For void there are no such things.

Does not matter. It's a CLR architecture mistake in the first place. There could be a slot with a well-known type "nothing". Clear distinction between "there is a slot" and "there is no slot" is a mistake. It's just a poor architecture design indeed. CLR does have lots of good architecture design decisions, but void as it implemented is an example of rare poor design decisions in CLR.

CLR is designed to be a "language agnostic" to a large extent and C# itself is a multi-paradigm language, but void as it implemented in CLR is a hardcoded C-like "special case" feature which architecture design smells.

[GeirGrusom]

It's just a poor architecture design indeed.

Isn't that a little strong language to use?

Take it from the CLR perspective. If void acts like a normal value you would have to pop it from void returning functions (and you would always have to pop it) which would probably be a massive WTF for compiler writers in .NET 1.0 which didn't have generics. It would seem like completely pointless ceremony.

[HaloFour]

@Opiumtm

CLR is designed to be a "language agnostic" to a large extent and C# itself is a multi-paradigm language, but void as it implemented in CLR is a hardcoded C-like "special case" feature which architecture design smells.

It's not a C-like special case, it's an imperative programming normal case, and it applies to the majority of the programming languages. All CPUs have this exact same design. You don't push/pop nothing. It's the functional language compilers that hide that reality from you, and nothing prevents them from doing that here as well. It's silly to suggest that all of the non-functional languages (read, every language designed by MS in the .NET 1.x timeframe) should have to work around design decisions specific for functional languages.

[Opiumtm]

@GeirGrusom

Isn't that a little strong language to use?

"poor design" is a strong language? Well...

If void acts like a normal value you would have to pop it from void returning functions (and you would always have to pop it) which would probably be a massive WTF for compiler writers in .NET 1.0 which didn't have generics. It would seem like completely pointless ceremony.

Not so pointless as it would allow to chain function invocations and to do many useful tricks as you can do it with any form of homebrew unit return. I do undesrtand that CLR was designed with imperative and pure OOP intent in the first place, but as reality itself prove it, successful languages are multi-paradigm languages which allows to do more things with less limitations. So it's true for low-level virtual machine architecture as well.

It's like a "type erasure" in Java's generics implementation. Because Java wasn't designed for generics in the first place then generics was implemented in lame way on the top of the existing VM specification.
There was a major CLR update without full backward compatibility when .NET 2.0 with generics was introduced. It was a time when proper implementation of "nothing" value should been introduced. And even when .NET standard libraries was updated to use generics there was clear that in regard to generics the legacy understanding and implementation of void pseudo-value was incomplete and poorly compatible with generics concept.

[Opiumtm]

@HaloFour

Unit is a tuple with no values. Void is no tuple.

Unit is a type which does have only one valid value. Only one valid value means that such a type contains exactly no information. So unit is not a tuple. Even if it's seen as "tuple with no values" in functional languages, it's just a functional language's point of view on unit type which is canonically defined as a type which does have only one possible valid value. In regard to amount of information "only one possible value" is a full equivalent of "no value". See above, for type to contain at least one bit of information, such type should have at least two valid values.

Unit has storage.

What storage? Unit does not contain any information. There is nothing to store. Even if actual unit implementation does have some kind of (actually unused) "storage", it's just an implementation detail.

You might view that as a mistake but that's through the glasses of someone who wants the world to conform to the functional notion that everything must be an expression. Thats not true in the CLR, or C#, or most programming languages.

I'm saying it not from the point of view of "functional languages adept", but from the point of view of a person who thinks that OOP, functional, imperative, etc are just convenient abstractions around same things. There is a joke about "closure is a poor man's class" and then "class is a poor man's closure". This joke reflects a fact that OOP and functional languages in reality are abstractions designed to express same things, but from a different convenient points of view. OOP languages and functional languages are both practical applications of same mathematical theories, but for different people and for different real-world tasks.

And also

through the glasses of someone who wants the world to conform to the functional notion

Current understanding of void is very harmful for generics too.

[HaloFour]

are just convenient abstractions around same things.

Convenient but different abstractions. The CPU, like the CLR, has no concept of "zero-sized structs" or "empty values". You have addresses and you have opcodes to operate on those addresses.

Functional approaches "empty" differently from imperative. As a result, unit and void are not the same abstractions for the lack of data.

Current understanding of void is very harmful for generics too.

The concept of void and generics are inherently incompatible. What is a List<void>? What is a Action<void> and how many arguments does it take? The lack of an action. The lack of opcodes. You cannot encode that in generics.

It's all moot anyway. This conversation has happened several times and based on the few comments from the LDM they have no appetite to take on such a massive task given that it wouldn't benefit any of the existing APIs.

[OnurGumus]

Sorry for interrupting but don't you think this discussion is counterproductive?

[HaloFour]

@OnurGumus

Sorry for interrupting but don't you think this discussion is counterproductive?

I agree.

I do like the idea of adding unit to the language as an empty struct, perhaps as an alias to System.ValueTuple since that already exists. I also like @Joe4evr 's suggestion of having the compiler treat that as void in those scenarios where it can, e.g. not requiring you to return a value:

public unit Foo()
{
    if (someCondition)
    {
        return; // no return value required
    }
    doSomeStuff();
    // no return statement required
}

It'd also be nice if the JIT could recognize such patterns with this "empty" struct (or any "empty" struct) and perform additional optimizations.

[DavidArno]

I think we can take it as read that the CLR was not designed to accommodate a unit type properly and that it would not be feasible to shoe-horn such a type into it at this stage. That especially applies to any interop between unit and void, which seems nigh on impossible without breaking something, somewhere. It's a great shame, but that's the way it is.

But that is orthogonal to this proposal, as far as I can see. All that's being asked for is that ValueTuple be provided with the alias unit to encourage the adoption of a single unit type.

I personally would also like to see () adopted as the (non)value for unit:

unit Foo() => ();

It's a simple change that achieves 80% (made up figure) of what's required. so is probably good enough.

[Kukkimonsuta]

I've recently discovered the need for unit and using ValueTuple is nice idea. Aliasing unit == ValueTuple and () == new ValueTuple() would be quite helpful for this case, but I'd like to ask some questions:

1. What is the interop scenario with F#? Currently there is Microsoft.FSharp.Core.Unit - is there any way both languages can migrate to same thing? Would more explicit System.Unit make that easier?
2. Is there any risk of breaking future efforts to bring more functional features into C# by introducing such alias?

[theunrepentantgeek]

Creating an official alias/keyword for unit has merit, but I worry that any compiler based magic compatibility has a real risk of causing problems.

To illustrate, assume you have the following declarations:

private R Apply<T,R>(Func<T,R> func, T value) => func(value);

Func<string, int> alpha = s => s.Length;
Func<string, unit> beta = s => Console.WriteLine(s);

Both alpha and beta can be passed to the method Apply() in the way you'd expect:

int a = Apply(alpha, "demo"); // returns 4
unit b = Apply(beta, "demo"); // returns unit

To achieve compatibility between Func<T,unit> and Action<T>, we'd need a bit of compiler magic - because Func<T,unit> returns a value on the stack that would need to be discarded, and Action<T> does not. (IIRC, this is a fact of the CLR that we have to accommodate, no amount of hand-waving allows us to ignore it.)

What if we now have these declarations:

private void RegisterCallBack(Action<T> callback) { ... }
private void DeregisterCallBack(Action<T> callback) { ... }

Action<T> delta = ...
Func<T, unit> gamma = ...

(This based on a common code pattern I've seen and used many times.)

When we pass delta to these RegisterCallBack(), the implementation keeps a reference to the delegate for later use. Later on, a call to DeregisterCallBack() with the same delegate allows it to be removed.

RegisterCallBack(delta);
...
DeregisterCallBack(delta);

We can't pass gamma directly to these methods, they're not type-compatible - remember that gamma returns unit where nothing is expected at all.

The compiler could wrap delta in another delegate to do a conversion, like this:

Action<T> gamma` = v => gamma(v);

Unfortunately, this means the delegate actually passed to DeregisterCallBack() won't be the same one passed to RegisterCallBack() even if the argument used looks like it is.

This is exactly the kind of subtle bug that would lead a team to say "Avoid unit at all costs, it's buggy." and that would be unfortunate.

There are other consequences too, including a performance hit for bouncing through the extra delegate (admittedly low, but certainly not zero) and an increase in the heap overhead of using delegates.

[zastrowm]

but I worry that any compiler based magic compatibility has a real risk of causing problems.
...
To achieve compatibility between Func<T,unit> and Action, we'd need a bit of compiler magic - because Func<T,unit> returns a value on the stack that would need to be discarded, and Action does not. (IIRC, this is a fact of the CLR that we have to accommodate, no amount of hand-waving allows us to ignore it.)

I wonder if simply adding support for unit in method definitions would be enough. My core problem with not having a unit type is that it requires either adding signature overloads for both Action & Func or requires the method declaration to use a placeholder type and explicitly returning it. But if the compiler allowed omitting returning a value when using unit, then one could simply expose Funcs everywhere instead of Action & Func, assuming the consumers could use unit.

For example, it allows consumers to declare this:

public unit Foo()
{
    if (someCondition)
        return; // no return value required

    doSomeStuff();
    // no return statement required
}

instead of

public NoReturnValue Foo()
{
    if (someCondition)
        return NoReturnValue.Instance;

    doSomeStuff();
    return NoReturnValue.Instance;
}

[HaloFour]

@theunrepentantgeek

You couldn't pass gamma to those methods anyway. With the way delegates are nominally typed even if the compiler/CLR could somehow smooth out the signature differences you still couldn't treat the Func<T, unit> like an Action<T>. Even between two delegates with equivalent signatures you'd still be wrapping the one with the other, like from Func<T, bool> to Predicate<T>.

It's my opinion that the addition of unit to the language has to be viewed as to the benefits it brings with zero impact on generics, as I'm quite certain we're not going to see the effort made to modify the CLR to make any of that happen.

Compiler magic to make unit feel like void even has numerous pitfalls, like around lambdas and generic inference. Take the following snippet of code, which is legal today:

using System;
public class C {
    public void M(Action a) { }
    public T M<T>(Func<T> a) => a();
    
    public void M() {
        M(() => Console.WriteLine("foo"));
    }
}

In adding unit to the language and support for unit in void lambda expressions above it would be important that the compiler handle overload resolution exactly as it does today and to call the non-generic overload of M.

[OnurGumus]

Or perhaps we can solve this problem by using aliases: #1170

[IS4Code]

Functional languages need a unit type due to the distinction between a function and a procedure. Since methods can either return "something" or "nothing", representing a new "nothing" type in addition to void adds just more language clutter. The BCL could provide a default Unit type for interop between functional languages, but C# is not one of them.

Besides conveniency for generic types, I see no other use. For generic types, I think void should be applicable as a generic type argument for delegates and interfaces where it appears only in an output position, kinda like with covariance.

[Joe4evr]

I think void should be applicable as a generic type argument for delegates and interfaces where it appears only in an output position

There's a problem with this:

public int M<T>(Func<T> func) //'T' is the output, like you said
{
    var t = func(); //whoops, can't do this for 'void'
}

[IS4Code]

There's a problem with this:

public int M(Func func) //'T' is the output, like you said
{
var t = func(); //whoops, can't do this for 'void'
}

Unless void is valid only for delegates and interfaces, in which case it could not be inferred as a parameter for M. I agree it has a limited number of use cases apart of simplifying implementation of some interfaces, but it is a fine first step.

Edit: An example of a use case I can think of:

interface ICaller<T>
{
    T Call<TArg>(Func<TArg, T> f);
}

ICaller<void> would be practically equivalent to an interface with a method taking Action<TArg> and returning void.

[OnurGumus]

Functional languages need a unit type due to the distinction between a function and a procedure. ... but C# is not one of them

@IllidanS4, you are wrong! C# is also a functional language.

[iam3yal]

@OnurGumus Nop, it support some functional features and it starting to look more and more like one but it lacks other things that functional languages has and C# is not there yet.