Discussion: Better support for "Unit"

[HaloFour]

There have been numerous proposals looking to add first-class support for a unit type to the language. I'd like to explore the different individual ways that the language could do this without CLR modification.

This is an open discussion and I invite comments and suggestions. I'll get the ball rolling with some of the ideas I've seen in comments buried in other proposals.

Create a unit alias

The family of types called System.ValueTuple<...> were added to the .NET 4.7 framework to support tuple literals in the C# language. There exists a version with 0 elements, System.ValueTuple. It primarily contains static factory methods for creating instances of the other tuple structs, but it is a struct in its own right and can be created. It is an effectively empty struct with no public fields and is suitable for representing unit.

Func<unit> f = () => default(unit); // or just default

// equivalent to

Func<System.ValueTuple> f = () => default(System.ValueTuple);

The name, however, could leave a little to be desired. I'll continue to use System.ValueTuple for examples here but I'd leave that point open to discussion.

Support () literal to mean unit

The syntax () could be shorthand to represent default(unit):

Func<unit> f = () => ();

// equivalent to

Func<System.ValueTuple> f = () => default(System.ValueTuple);

Implicit conversion from void to unit

The compiler could support conversion from void to unit by emitting IL necessary to push default(unit) onto the stack:

Assignments:

unit u = Console.WriteLine();

// equivalent to

Console.WriteLine();
System.ValueTuple u = default(System.ValueTuple);

Lambdas:

Func<string, unit> f = value => Console.WriteLine(value);
// or
Func<string, unit> f = Console.WriteLine;

// equivalent to

Func<string, System.ValueTuple> f = value => {
    Console.WriteLine(value);
    return default(System.ValueTuple);
};

[masonwheeler]

This discussion of how to implement unit does not address the more fundamental question of why. We've gotten along just fine without it, and most of the arguments in favor seem to be requesting that useful semantic information be removed, which makes no sense. Can we please not do things that will make the language less useful?

[Neme12]

What about delegate/method group conversions? There wouldn't be conversions between Func<string, unit> and Action<string> I assume?

[jnm2]

@Neme12 I hope not because those conversions would be expensive and there's an easy workaround: return default;.

[DavidArno]

@Neme12,
To my mind, having unit and being able to use void methods with Func<unit> really removes the need for Action and thus removes the need to handle such conversions.

@masonwheeler,
The use case for me is to remove code duplication. I have quite a lot of code that is near identical, save for one version taking a Func<T> and the other taking Action. Being able to pass void methods in to the Func<T> version as Func<unit> would remove that duplication in an instant.

[Joe4evr]

@Neme12 There will not, just like there's no conversion between Func<T, bool> and Predicate<T>.

[HaloFour]

@masonwheeler

We've gotten along just fine without it, and most of the arguments in favor seem to be requesting that useful semantic information be removed, which makes no sense. Can we please not do things that will make the language less useful?

What about this discussion makes the language less useful? What semantic information is being removed? void and unit aren't synonymous, but they're close enough. The big difference being that the former can't be used in expressions (usually) which immediately splits the language in half between statements and expressions often with poor/verbose ways of bridging the two.

@Neme12

What about delegate/method group conversions?

What would make it any different to creating a delegate to the method group Invoke on another delegate?

Action<string> a = () => Console.WriteLine;
Func<string, unit> f = a.Invoke;

[HaloFour]

@jnm2

I hope not because those conversions would be expensive and there's an easy workaround

The idea being that the compiler would emit that easy workaround:

Action<string> a = () => Console.WriteLine;

Func<string, unit> f = a.Invoke;

// equivalent to:
Func<string, unit> f = () => {
    a.Invoke();
    return default;
};

Yes, you incur the cost of two delegate invocations, but that's no different than:

Predicate<Person> p = person => person.IsAlive;
Func<Person, bool> f = p.Invoke;

[iam3yal]

The details are different but Kotlin has a similar thing.

[Neme12]

I hope not because those conversions would be expensive

Yes. But this also makes me want this feature less. There would be an implicit conversion in some places (giving the impression that void and unit is interchangable) and not others.

To my mind, having unit and being able to use void methods with Func really removed the need for Action and thus removes the need to handle conversions.

But Action still exists and would continue existing for a long time in existing APIs. How would you interoperate with them?

[jnm2]

@HaloFour Action<string> a = Console.WriteLine;, right?

I'm happy with Func<string, unit> f = a.Invoke; adding syntactic sugar but not happy with Func<string, unit> f = a; if the compiler generates a runtime stub for that. I think that's what @Neme12 was talking about.

[masonwheeler]

@HaloFour

What about this discussion makes the language less useful? What semantic information is being removed?
...
The big difference being that the former can't be used in expressions (usually) which immediately splits the language in half between statements and expressions

You just answered your own question there. The distinction between statements and expressions, and also also the distinction between methods that return a value and methods that don't, is valuable and important. Let's not go blurring it please!

[jnm2]

@masonwheeler Sounds a lot like the hallowed distinction between classes and interfaces, if you ask me. 😇

[jnm2]

@HaloFour In other words, to answer @Neme12, I don't want there to be implicit conversions from one delegate instance to another at the language level, since they invisibly opt you into using compiler-generated stubs and you lose reference equality. But once you opt in by explicitly creating a new delegate instance, such as binding to .Invoke, it makes more sense (I think). Still not sure on that point since there is additional overhead.

[DavidArno]

@masonwheeler,

What I'd really like is for void methods to push void onto the stack and thus to become just another function, completely obliterating the distinction between methods that return a value and methods that don't, because it's neither valuable or useful in my view.

However, what @HaloFour is proposing avoids that. void methods remain as methods that do not return values. Action remains. But we also get a means of treating those void methods as Func<unit> when it's useful to do so. This is comparable to statement expressions being able to be used in expression-bodied methods. They are still statements, but can be used as expressions sometimes. Likewise void methods remain void methods with this proposal, but they can be used with Func<> sometimes.

[HaloFour]

@masonwheeler

I'm not seeing the value in either. The language forcing you to use two sets of constructs based on whether or not a method returns a value is not a value to me. It's a hindrance which requires code duplication and bridging that adds no semantic value to your program.

@jnm2

I completely agree. I'd treat it the same way as delegate conversion between delegates with matching signatures, which C# doesn't allow today due to the argument of the overhead. If that were to change I'd probably back implicit conversion as the overhead comes from the duplicate delegate invocation, not from pushing unit onto the stack.

[CyrusNajmabadi]

Note: an example of where we did CLR work and where i think it really helped prevent problems is with 'nullable' (for value types). For example, i think it would have been pretty awful if boxing a !HasValue nullable-int produced a non-null boxed valued type. It would have been painful and totally strange, and it turned out to be really good that you actually just get the 'null' reference value when you try to do this.

To me, i would want the same for what i see as hte input/output stream of values. I want that to be a first class concept (which i think would almost certainly require CLR support). But that means that you'd need to do things like unify the concept of 'parameter lists' and 'tuples' and whatnot. And right now, we've already shipped tuples. The CLR is completely oblivious to them. And trying to change that would almost certainly be breaking. So just accept that the (currrent) CLR world just has no consistent view of these guys, adn i accept that that's likely to not change. It's ugly. It's unfortunate. And i truly hope a new restart would address this.

[HaloFour]

@CyrusNajmabadi

Do you expect i would be able to do:

ISink<unit> sink = ...;
sink.OnEvent();

?

Or would i have to pass actual values to the 'unit' arg of 'OnEvent'?

I'm undecided. It'd be neat to be able to pass nothing, but that seems like it could get really messy really quick, especially if OnEvent already had an overload accepting zero parameters. But I guess that's no different than OnEvent(T) clobbering OnEvent(int) when T is int.

Similarly, when working with Func<unit, string> would you call it as func() or func.Invoke()? How about Func<unit, string, string>? Would that be callable as func("foo")?

There's a lot of questions here and a lot of things that the language could probably do.

[iam3yal]

@CyrusNajmabadi

Or would i have to pass actual values to the 'unit' arg of 'OnEvent'?

In Kotlin, you will have to provide a value; otherwise, the compiler will throw an error.

It seems like people expect more from the type than what it really represents, just my opinion about it.

[HaloFour]

@CyrusNajmabadi

I mean, say you had this today:

(int, string) GetValues();
...
void Foo((int, string) t) { }
void Foo(int i, string s) { }
...
Foo(GetValues());

In my ideal world, this would be calling the latter method. You have something returning two values, and you have something taking two values. These should align. However, in the existing C# view of the world, this calls the first, and it could definitely break things to make it call the second.

Yes, the C# compiler would have to call the first overload. But there's nothing stopping the C# compiler from calling void Foo(int i, string s) if that first overload didn't exist by automagickally splatting the tuple. I do believe that there are proposals here to do just that.

[philosaurus]

@CyrusNajmabadi @HaloFour

I'd really love to be able to squash argument lists and have them treated as equal. Action<unit> being the same as Action, sounds natural: both take nothing of interest and return nothing of interest. I couldn't care less how it's implemented, but I want it to work.

This whole area of delegate compatibility is a mess. (Predicate<T> and Func<T, bool> anyone?) Would a function with the signature void f() be a valid Action<unit>? Func<unit, unit>? If there's a method that accepts Action<unit>, can I pass it f? Would the compiler wrap it in an another method that just swallows the argument and call my original function? Could I pass void g(int) to Func<int, uint>?

Would void f<T>(Func<T> x, string y, Func<T, string, unit> z) { z(x, y); } be legal with T = unit? Could z have the declaring signature of void f(string) or would it have to be unit f(unit, string)? Outside of generics, could both void f() and void f(unit) exist?

It's not that I don't want nice features, but I want them to work without headaches. I don't see how this singleton unit blends into the already existing, bigger picture. Maybe if you're designing Scala, Kotlin and others from the ground up, and consider this from the very beginning, then it's a workable idea. At this point in C# I can only see it causing subtle problems. But I'm really up for being convinced otherwise.

The reason why I'm advocating "proper" (CLR-based) void support is because if you turn void into a first-class zero-sized type, at least the binary signatures would match. I understand it's a lot of work and everything, but I just don't feel myself convinced that this solution won't end up bringing more, obscure incompatibilities than it solves. As I mentioned earlier, I'm somewhat tired of having half-baked solutions: otherwise great ideas that turn out to be disfunctional or limited in obscure ways because of ... reasons.

And, while I've always wanted to write ((((),((),(),())),((()),()))), overuse of parentheses in the language (precedence, function call operator, parameter lists, casts, tuples, unit) can quickly turn C# into an IOCCC-worthy language.

[qrli]

@CyrusNajmabadi

(int, string) GetValues();
...
void Foo((int, string) t) { }
void Foo(int i, string s) { }
...
Foo(GetValues());

I agree it would be cool if we had that. But may I ask what's the drawback as we do not have that. I have used the splat/unpack operator, e.g. in Python *tuple or in Powershell @array. It does not feel too bad to me.

[Thaina]

You just devolved your own argument back into whether or not unit means void

This is important to consider that, with any mechanism or implementation detail aside, do we really need unit keyword and type on its own. Or we could just disguise it as context sensitive void in C# as a language

I may support changing CLR to accept void as a type. But I am not against the hack to introduce mechanism of unit into the language to bridge the gap. I just against the idea of exposing unit keyword and System.Unit into the C# language. This is difference story even we have talk it both at the same times. It just need a bit of concern to each other

To be clarified, I would support the effort to trying to disguise void in some context and transpile it as System.CSharp.Void (which is arguably unit in disguise). It just that we should not be name it unit and should not introduce the concept of unit into C# for all eternity. Because in the paradigm of C# we should not have concept of unit but we should strict to concept of void for no information and no value. And if there would be a single value to represent the absence of information then it should be null

[Korporal]

C# is morphing from a rather well designed imperative OO language into a bastardized language that is copying more and more ideas from the functional world, in particular from F#. Looking over the LDT meeting minutes recently it is clear that there is a heavy bias toward functional programming features.

Functional programming languages are superb and I use F# when I can at my own place of work, however the trend to morph C# into a mutation of F# must be questioned.

It can also hardly help in the adoption of F# when C# is increasingly positioning itself as an alternative.

Microsoft offer F# already so why strive to adapt C# to look more and more like a functional language?

As I've said elsewhere dwelling on esoteric functional mechanisms while flatly rejecting rudimentary and pretty obvious enhancements (e.g. break with labels in loops) seems to amount to a program of completely transforming the language, this is silly when - if we truly desire functional concepts - we can simply begin to leverage F#.

C# developers (or rather OO developers) do not design or write functional code, the C# language itself is not a functional language nor is it wise to try and make it into one especially when Microsoft already provide one!

[svick]

@Korporal

Microsoft offer F# already so why strive to adapt C# to look more and more like a functional language?

F# is functional and immutable first, with object-oriented and imperative features added on top.

C# is object-oriented and imperative first, with functional and immutable features added on top.

Personally, I like the latter approach, which is why C# is my primary language and why I also like that functional features are being added to C#.

As I've said elsewhere dwelling on esoteric functional mechanisms while flatly rejecting rudimentary and pretty obvious enhancements (e.g. break with labels in loops) seems to amount to a program of completely transforming the language

The basis of C# is and always will be an imperative and object oriented. But most importantly, C# is pragmatic. If a functional feature, like lambdas or pattern matching, will improve the language, it will be added to it.

Also, I don't understand how "a feature I like won't be added to the language" means the language is transforming.

[tannergooding]

Looking over the LDT meeting minutes recently it is clear that there is a heavy bias toward functional programming features.

@Korporal, there is no one true programming paradigm. There are benefits to exposing many different paradigms in order to best support whatever makes your code easier to read/write.

F# is a functional first language, but it is by no means a functional only language (I can use OO patterns when and where required).

C# is likewise not only a imperative OO language (even if those are generally agreed to be its "primary" paradigms). It exposes many different paradigms to help you write your code.

Sometimes "functional" features let you have clear cut benefits (purity and immutability allow certain optimizations that you could not otherwise guarantee were possible). Likewise, in some cases, "functional" features can hurt you (I don't want to have to write a monad to have a functional UI stack).

[HaloFour]

@Korporal

C++ also has lambdas and "unit" (std::monostate). The imperative/OOP languages have all pretty much recognized that there are a great deal of benefits to adopting features from functional languages.

C++ doesn't have labelled loops, though.

[jnm2]

If I have a custom type with an implicit conversion from unit, I would like to be able to have an implicit return unit; at the end of the method.

action =>
{
    if (action is AsyncThunk thunk)
    {
        thunk.Invoke(store.GetState, store.Dispatch); // No return on the following line
    }
    else
    {
        return next.Invoke(action);
    }
}

[StefanBertels]

(+1) for having built-in Unit type (with only value unit).

There are multiple great libraries like LanguageExt by @louthy (he commented above) or Reactive Extensions that already define their own Unit type. This results in requests to make them compatible: https://stackoverflow.com/questions/58986333/using-the-unit-type-from-mediatr-and-reactiveui-and-language-ext

Obviously there is a demand and I'm sure many people regularly creating generic code or using expressions (LINQ, fluent APIs etc.) will value it a lot.

[garyng]

(+1) for having built-in Unit type (with only value unit).

There are multiple great libraries like LanguageExt by @louthy (he commented above) or Reactive Extensions that already define their own Unit type. This results in requests to make them compatible: https://stackoverflow.com/questions/58986333/using-the-unit-type-from-mediatr-and-reactiveui-and-language-ext

Obviously there is a demand and I'm sure many people regularly creating generic code or using expressions (LINQ, fluent APIs etc.) will value it a lot.

... and MediatR has its own Unit type too.

To avoid confusion (and "unify" them), I can't name my type Unit; then there is System.Void so I can't name my type Void; not Empty because it means Bottom and has different meaning; not Single because there is System.Single...

Should I name it One? Or Yi (which is the pinyin of 一, "one" in chinese)? Or Satu ("one" in Malay)?

In the end, I'm just a normal library user and I can see there is a need of a Unit type, no matter how it is implemented.

[neon-sunset]

There is definitely an argument to be made in favour of Unit expressions where void is coerced to () which would, in turn, be a valid return type.

This could enable writing switch expressions where inferred return type is () allowing to put e.g. Console.WriteLine() at its arms, without having to introduce new or change existing switch statement syntax e.g.:

_ = value switch // removing the requirement for _ = becomes very easy
{
    1 => Console.WriteLine("one"),
    >= 2 and < 10 => Logger.Info("two"),
    _ => Debug.Print("other")
};

[CyrusNajmabadi]

Note: we can just make such a switch expression work (and we've expressed interest in exactly that), without need for a unit type.

I say this as someone also interested in having a unit type:-)