Proposal: Allow Void type as a Generic parameter

[kind-serge]

Currently, void is not allowed as a generic parameter for a type or a method, what makes it hard in some cases to implement a common logic for a method, that's why we have Task and Task<T> for instance.

However, nothing stops you from defining your own Void type like this:

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

and use it as a generic parameter for any type or method.

This solves the problem is your app, but your own Void type is not the same as built-in System.Void, even though they are semantically equal, what introduces a confusion for a consumer that does type analysis when using reflection for instance.

Now with your own Void type you are obliged to use the return statement in methods:

MyNamespace.Void FunctionAsProcedure()
{
    // must use return statement, even though the type size is 0
    return default(MyNamespace.Void);
}

what is not a requirement for System.Void. This optional use of the return statement should be considered as an optimization for well-known 0-length value types.

Thus, the System.Void must support the new operator, and must be allowed (but not required) to be explicitly returned as the result of a method.
Such behavior intersects with another feature request: Allow return void function with void function.

[mikedn]

even though they are semantically equal

How so? You can create an array of type MyNamespace.Void[] but you can't create an array of type void[]. Same for fields - you can have a field of type MyNamespace.Void but of type void. They're obviously semantically equal. What you're really saying is that you'd like to change the semantic of void to be like MyNamespace.Void.

This optional use of the return statement should be considered as an optimization for well-known 0-length value types.

There's no such thing as a 0 length value type. Your Void type has in fact size 1. The idea of a 0 length value type is rather bizarre, among other things this means that the following code would generate a division by 0 error:

long distance(Void* p1, Void* p2) => p2 - p1;

[svick]

1. The type System.Void already exists, but it's very special. You can't even write typeof(System.Void) (typeof(void) works) and you can't create an instance of that type. If you wanted to reuse this type, I belive the CLR would have to be modified. Some related discussions: Suggestion: void as a first-class citizen roslyn#234, https://github.com/dotnet/roslyn/issues/14424.
2. In functional programming in general, and in F# in particular, a unit type is used for this purpose, which is considered equivalent to zero-tuple. Zero-tuple already exists (in the form of the non-generic System.ValueTuple), but it doesn't have language support in C#. Maybe this type could be used instead? See also: zero- and one-element tuples roslyn#16313.

[mikedn]

The type System.Void already exists, but it's very special.

Strictly speaking it's not even a type. If it weren't for pointers (where it has to sort of behave like a type for consistency and simplicity) maybe it wouldn't even exist. void could have been just a language keyword indicating that the method doesn't return anything and MethodInfo.ReturnType could just return null for void returning methods.

[kind-serge]

@mikedn,

1. Those types are semantically equal - i.e. they mean the same, but you are right that you can do different things with them - that's not semantics.
2. Actual size is 1 - that's should not be related to the language specs, it's rather a compiler/runtime implementation details.
3. The example with pointers is not good - a pointer size depends on bitness of your compiled application, and subtracting pointers gives you a pointer.

[HaloFour]

This suggestion was already argued over on Roslyn. The issue is that it would require quite a few changes to the CLR and at this point wouldn't help much since many of the core APIs are already written. Rather than trying to shoe-horn the existing concept of void into the equation I'd rather the BCL simply provided its own Unit struct.

[mikedn]

that's not semantics

But what is it?

and subtracting pointers gives you a pointer

No, subtracting pointers gives you a long, the distance in objects between those pointers. Since pointers are really memory addresses that means that p2 - p1 is in fact ((long)p2 - (long)p1) / sizeof(object_type).

[tannergooding]

I think the fact that subtracting two pointers in C# giving you a long is an implementation detail.

If C# had proper support for IntPtr/UIntPtr from the beginning, it would have returned that instead (and not waste 4 bytes on platforms that don't need it). Two pointers subtracted from each other should give the equivalent of the native size_t.

[mikedn]

If C# had proper support for IntPtr/UIntPtr from the beginning, it would have returned that instead

Sure but that doesn't change the fact that subtracting 2 0-sized type pointers is not possible. If 0-sized types would be allowed then subtracting such pointers should be a compile time error, just like subtracting 2 void* pointers is today but for different reasons.

[Joe4evr]

I think the fact that subtracting two pointers in C# giving you a long is an implementation detail.

Well, this whole part of the discussion got started because of the fact that specifying Size = 0 for your own struct giving it a size of 1 is also an implementation detail.

[tannergooding]

@Joe4evr, specifying Size = 0 and giving a struct of non-0 is not an implementation detail, it is part of the CLI specification and is not up to interpretation.

The .size directive indicates a minimum size, and is intended to allow for padding. Therefore, the amount of memory allocated is the maximum of the size calculated from the layout and the .size directive. Note that if this directive applies to a value type, then the size shall be less than 1 MByte.

ClassSize of zero does not mean the class has zero size. It means that no .size directive was specified at definition time, in which case, the actual size is calculated from the field types, taking account of packing size (default or specified) and natural alignment on the target, runtime platform.

A ValueType shall have a non-zero size - either by defining at least one field, or by providing a non-zero ClassSize [ERROR]

[tannergooding]

Which is entirely separate from what a language decides to return when the delta between two pointers is taken, where the return type is up to the language and not defined by the runtime.

[ijsgaus]

Can be made with ValueTuple

[alrz]

Whatever it is, I hope we use void to denote it, that makes it transparent in case of type substitution.

interface I<T> { T M(); }
class C : I<void> { public void M(){} } // the compiler automatically emits `return` 

[kind-serge]

I feel like this conversation starts going slightly wrong direction. Let's set aside all thinking about void pointers, which are not allowed in generic methods (correct me if I'm wrong).

I'd rather scope this down to particular feature request to allow void in as generic parameters in types and methods, so that:

1. Methods with generic return types like:

T Method<T>()
{
    return default(T);
}

with void translate to:

void Method()
{
    return;
}

2. Allow parameters and fields of type void (when used as a generic parameter only).
   This is needed to support let's say async state machines, when you define an async method which returns Task<T> when T is void.

As @tannergooding mentioned the CLI specification, there must be no value type of 0 size, and System.Void is indeed defined as:

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

What makes it a pseudo non-unit type. I.e. there must be no issues with having fields and parameters of a value type that is 1 byte (or more) in size.

[HaloFour]

@TYROTOXIN

The method translation that you described is not possible. C# the compiler can only emit said method exactly once and the IL must work for any possible generic type argument. A method that returns a value must push the value onto the evaluation stack before ret. But a void method is required to have an empty evaluation stack. The same problem exists for callers. The size of the evaluation stack, which must be known by the C# compiler and predictable by the CLR before JIT or specialization, suddenly becomes completely impossible to calculate, and there's never a single set of valid IL instructions which can represent a generic method. And we're not even touching the possibility of void parameters.

At best you can treat System.Void as more than nothing, but that makes little sense, offers no benefit over a proper unit type and involves modifications to the CLR which are entirely extraneous. Comparatively, the effort to add System.Unit to the BCL is infinitesimal.

[Pzixel]

I want a unit type too and thought it might be a good idea to unify it with the existing void "type"
a) to make it feel like C# and not introduce any new keyword such as unit
b) because if this type allows us to omit a return statement, that essentially makes void redundant
... so these could actually be 1 thing and the fact that void methods compile to void would be sort of an "optimization" (but not really, it can't be an implementation detail and would have to be in the spec)

I think they are many pitfall in treating void as unit. It's quite dangerous to perform such a conversion. And I'm almost sure it won't be 100% backward compatible and thus a no-no for the LDM.

But if this is not realistic, an empty tuple type separate from void would still be useful. But with the empty tuple () is the syntax for both the value and the type: () x = ();. Is that possible and unambiguous? I tried to implement this and at first it seemed fine but after playing around a little more with casts the compiler started complaining about me trying to declare variables in an expression. But I'm definitely not an expert (and don't even understand all the parts that I changed).

I think we may just forbid unit type usage other than type declaration. You need is as generic argument only. If it's a unit type you don't need to compare it with anything - it's unit :) Why on the earth you need a value of the unit type? If you want return it just write return; just like for the void method. If you want to pass it as parameter you can use default keyword. In all other cases you are working with generic that may be of unit type, but you work with it as regular variable.

It's just an idea, it looks a bit hacky, but doesn't have mentioned issues and I see no drawbacks except some uglyness.

[quinmars]

@Pzixel again, there are no restrictions needed. Infact your proposed restrictions would invalidate the whole purpose of the unit type. If you cannot compare (Object.Equals) it, you cannot box it and then you cannot use it as generic type parameter. If the unit type does not have a default value, you cannot use it as a generic type parameter. You may take a look at a possible, already used, and useful implementation of the unit type: https://github.com/Reactive-Extensions/Rx.NET/blob/develop/Rx.NET/Source/src/System.Reactive/Unit.cs

It's not harmful to use the unit type as what it actually is/should be: a normal value type.

[Pzixel]

@quinmars why whould you like to run object.Equals? You don't have to compare unit object because it's a singleton. You don't have to box it because you want to box an emptiness. You obviously can use it as generic parameter but you cannot create a value of this type because it's useless.

If you thing the opposite provide any use case when it's necessary to declare a variable of type Unit, which is not monomorphed generic (i.e. T t = new T(); for T: Unit is valid while Unit unit = ... isn't).

[quinmars]

static T Default<T>(T o) => default(T);
static Object ToObject<T>(this T v) => v;

Both are valid generic methods.

You obviously can use it as generic parameter but you cannot create a value of this type because it's useless.

So how does that fit together?

[Pzixel]

@quinmars I think these methods are allowed to be used by the compiler but not by the user. If you are comparing two Unit objects then you just don't understand what is it.

[quinmars]

@Pzixel if (0 != 0) return; is also useless, but valid. I still don't understand why you want to restrict the usage of the unit type.

[Pzixel]

@quinmars it's the same thing as empty statement ;. 99 out of 100 cases are just a typo. Unit it a bit different, it has NO valid usecases. 0 is on of ints so we just don't put an extra rule in the compiler. However, we show a warning anyway. And I always prefer rules that prevents typos at compile time rather than just show an ignorable warning.

[Neme12]

@Pzixel

Even with all your restrictions, things like List<unit> would still be allowed, which I'm sure you'd agree is also useless.

I don't think there's any reason to limit usage of this type. Yes, it's silly to have a variable of type void. It's also possible to make a lot of silly-looking expressions with the () syntax. But it's just as silly as doing this: {{{{}}{{}}}}{};. In fact it's silly to have an empty block on its own at all in your code - it doesn't do anything. That doesn't mean we need to ban it.

As you admit, there's a really easy "workaround" to get this to work - by making the method generic. I don't think we should introduce inconsistencies around having a generic vs non-generic version of the same thing. T should be replacable by the actual type without errors.

I don't think there's going to be an epidemic of people making void variables just for the sake of it. It's not like we're gonna have to explain to people "don't do that! it's actually useless" - people will be aware of that. Nobody writes code like this today, just because they can: {;{;{{}};;{;{((Action)(()=>{;}))();}}}}.

It's also silly to create an empty local function. And then call it. Or make a function that you don't call at all. But all of that should be legal. I don't think this is going to cause bugs either and therefore it doesn't warrant that we should ban it. There's no reason why we should pick and choose specific usages and make a list of what we think you don't need to do.

you cannot create a value of this type because it's useless
If you are comparing two Unit objects then you just don't understand what is it.

Do you understand what it is? The point of the unit type is that it does have a value - there's exactly one. No matter how useless it is. That's why it's called a unit type. Therefore comparison should always return true.

Unit it a bit different, it has NO valid usecases

Then what is this thread all about?

0 is on of ints so we just don't put an extra rule in the compiler.

We don't need any extra rules here either.

[Pzixel]

@Neme12 I admit that I have to agree. At least I have checked this code and it's pretty valid in Rust:

fn main() {
    let _ = ();
    foo((), ());
}


fn foo(_: (), __:()) -> () {
    
}

It's one of best designed language I know so if they are working this way then it's probably better than my silly proposal. I originally said that it looks hacky. Now you convinced me completely 😸

[aka-nse]

I think it is realizable this as user-code based syntax sugar in many case. How do you think?

• void return method will be wrapped by anonymous method which return Unit object when they will be assigned to generic delegate parameter.

  public void Foo<T>(Func<int, T> func) {}
  
  public void Bar(int arg) {}
  
  public static void Main()
  {
      // convert from
      Foo(Bar);
  
      // convert to
      Foo((arg) => { Bar(arg); return default(Unit); });
  }

• If there are several overloads, the one which do not need the conversion is always prior at name resolution.

  public void Foo(Action<int> func) {}
  
  public void Foo<T>(Func<int, T> func) {}
  
  public void Bar(int arg) {}
  
  public static void Main()
  {
      // resolve to Foo(Action<int> func)
      Foo(Bar);
  }

• If there are several overloads and all of them require the conversion, the caller will resolve to neither.

  public delegate T SomeDelegate<T>(int arg);
  
  public void Foo<T>(Func<int, T> func) {}
  
  public void Foo<T>(SomeDelegate<T> func) {}
  
  public static void Main()
  {
      // resolve to neither overloads (compile error)
      Foo(Bar);
  }

I think there are some advantages:

• Once concrete Unit type was decided, no modification for runtime or binary is need.

• All of conventional void return methods will get capable to assignment to generic return delegates just as it is.

• This is a syntax sugar and converted code is valid in current C#, so it may be able to be implemented comparatively easier.

[GratianPlume]

If we just do for Generic arguments, why not operates on the generic parser? We can use keyword "out?" to hold the void only for output.

to define a delegate:
public delegate TResult NewFunc<in T,out? TResult>(T arg);

use "_" to be a placeholder, and replace Action with NewFunc<T, _>.

so, we dont' change the void, don't need a new type，and don't worry about the old code. we only use the new speciation if we need.

[ghost]

I actually came across this thread when searching for a solution to this exact problem. I have a function that takes a Func<T> and returns the result (as well as doing some state changing behaviour). I have 2 versions, one with a Func<T> and one with an Action. To make it easier, I decided to make the void one call the T one. To fix the issue of being unable to use void as a generic parameter (which in my opinion is rather silly), I had to create a new function just to make it compile.

Simulate<int>( [parameters], () =>
{
    action();
    return 0;
});

As long as the value is not used (by passing it to other functions), I believe it should be possible, even if it's as simple as the CLR automatically returning null and forcing the result to be discarded.

[hez2010]

Even if C# doesn't allow void as generic parameter, I think at least the CLR should not block the use case. Otherwise it would prevent introducing a new language on top of .NET which has support for void as first-class type.

[HaloFour]

@jnm2

I wanted to point out that List<void> is a concept that makes sense.

I'm also not sure that's true. You describe it as some kind of counter, but in many of the languages that have a concept like this it would be impossible to add any values to it, because there are no values, so that would certainly not be the case. I think if it came down to a discussion as to how such a class should behave that there wouldn't be an agreement, although it might ultimately come down to the byproduct of whatever the implementation details happened to be.

[arsdragonfly]

@jnm2

How would that remotely work, tho? You can't have a value of void (let alone an internal buffer of void[]), so you can't add anything to the List<void>, so it could never grow.

If you wanted to be able to add items to it you'd need a value. In the Java world you can have Void as a type (and a generic type argument), but it's just a reference type that you can't instantiate, so you have to pass around null as the value. Or you have wildcard generics, like List<?>, but you're not permitted to add anything to it. But that doesn't unify generic paths either.

All of these ain't problems at all. Rust has zero-sized unit type. Unit type as struct field works. Unit type in a list (Vec) works. Eventually it becomes no-op after specialization. Generics code paths beyond these primitives are then unified. At some point we could introduce type aliases so that Func<void> and Action can be unified.

[HaloFour]

@arsdragonfly

Requiring several orders more magnitude of work to satisfy a severe niche case is an excellent way to ensure that the feature is never implemented.

[Neme12]

I'm also not sure that's true.

It would work exactly like List<Unit>, which you're suggesting as an alternative solution. But our point is simply that there's no need to create another type as void can be thought of as a unit type.

[HaloFour]

@Neme12

It would work exactly like List<Unit>, which you're suggesting as an alternative solution.

Should it? I don't like this idea that coming up with a "zero storage" space somehow accidentally causes it to behave like it might in rust.

But our point is simply that there's no need to create another type as void can be thought of as a unit type.

Even ignoring the runtime work, there are fundamental differences between void and unit. The former represents no value, the latter represents exactly one value. That value is what enables it to be used everywhere that generics are currently used. Without that you have to redefine void to mean something else entirely, and that's what brings all of this additional runtime work.

I think trying to shoot for how Rust does things is a fun and lofty goal, but I also think it's one quick way to ensure that these proposals remain permanently backlogged. Plenty of languages don't try to treat unit as zero-size and I wouldn't hold up such a feature to satisfy these extremely niche use cases.

So yeah, I think it's substantially easier and reasonable to add a new unit type and have it Just Work™️ (and List<ValueTuple> already does) with a tiny bit of additional syntax candy which would satisfy 95+% of the use cases for very little effort today than to continue to argue about these details for another 8+ years without a LDG champion.

Let me clarify, I'm not suggesting that the approach I'm suggesting is necessarily better, only that it has a much better ROI due to the substantially lower I. If the language and runtime teams came forward and said that they are interested in a zero-storage unit type (whether that be unit or repurposing void) and that they wanted to unify the generic and non-generic, I'd be all for it.

[marinasundstrom]

This is something that should be considered for C# 13, or 14, with the theme of bringing more functional programming constructs to C# - like Discriminated unions.

The issue is backwards compatibility with existing APIs. It would certainly break stuff. That is probably why it will never happen.

Adding stuff to the language without supporting it fully in the framework would make .NET seem bloated.

Perhaps we need a new language for this - if we want to make drastic changes to C#.

[hez2010]

This feature can also be useful once we have union types. (T or void)/OneOf<T, void> can represent the return type of a method which may return a T or nothing.

[dersia]

isn't this why the uniontype proposal contains an option type?