Docs: Void is also a built in type

[abelbraaksma]

We should probably include void into this list. It's a built in type, though it cannot be used directly, unless through reflection. We could also simply add it as a note or remark.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: fe245daf-f6b8-1100-3786-b15feefe137b
• Version Independent ID: c031bb57-cb5b-f953-4711-a0ed054dab3f
• Content: Built-in types - C# reference
• Content Source: docs/csharp/language-reference/builtin-types/built-in-types.md
• Product: dotnet-csharp
• Technology: csharp-language-reference
• GitHub Login: @BillWagner
• Microsoft Alias: wiwagn

[BillWagner]

Thanks for raising this @abelbraaksma We should mention void.

I'm not sure this is the correct article though. void isn't mentioned in the C# specification on Types. There are many locations where a type identifier is used where void is not allowed:

• Type of a property or indexer
• Generic type argument
• variable or field declaration
• is and as operators.
• type patterns (switch and is)

In addition, the spec makes a special case of typeof(void) to represent "the absence of a type".

I'm adding the "discussion" label, because I agree this needs to be covered. Before making changes, let's continue to consider how to present it.

[pkulikov]

The minimum possible update is the link to the void article in the See also section (like it's for dynamic now).

[abelbraaksma]

In addition, the spec makes a special case of typeof(void) to represent "the absence of a type"

Indeed, which happens to be an actual, public type, System.Void, even though it represents the absence of a type. And that actual type is very much built in, even though you can't instantiate it from C#. It's internally represented as an empty struct.

You're right that it isn't a normal type. But users encounter it everywhere in their code, I'd argue it wouldn't hurt to add a note. Something like:

The special built in type void isn't part of this list as it cannot explicitly be instantiated, nor accessed, unless with typeof. It can be used, however, with reflection, where it represents a type that means the absence of a type. More info: \.

[pkulikov]

@abelbraaksma

But users encounter it everywhere in their code

Do they treat it as a type? For example, when I learnt C#, I didn't treat void as a type, I was told: "Want a method that returns nothing? Use void". That was like a special keyword. I doubt that when one encounters void in the code, one goes to the page about the built-in types. However, one would definitely go to the dedicated article.

Coming back to the article in discussion, I still think the link in the See also section would be enough. Another option is to just add one more row to the table of value types (that would be still technically correct).

[abelbraaksma]

Perhaps I'm viewing this too much from a theoretical stand point, in part from my background in functional programming (every function returns something, in F# the equivalent to void is unit, which is a full type), or even type theory. Likewise, where an empty set is also a set. And so, a type representing the absence of a type is also a type.

This may be a little too far from the practical day to day use, and you're right, maybe it's normally viewed as a keyword (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/), but so are int, object long and null. And like null means the absence of a reference to an object, but is itself a value, void means the absence of a type and is a type.

Though null is an (empty) instance of any reference type , void cannot represent any type.

Either way, I'll concur with whatever you decide. It just struck me as odd, but I do understand your viewpoint as well.

[pkulikov]

@abelbraaksma the more I think about it, the closer to your point I am. To the very end of the article, I would add a shorter note that reflects the most common usage of void:

void is the special built-in type. You use it as the return type of a method that doesn't return a value.

(In the paragraph above, "void" would be a link to the dedicated article.)

What do you think?

[abelbraaksma]

I agree, though I'd posit a slightly modified text (namely s/the/a) :

void is a special built-in type, used primarily as the return type of a method to indicate that it doesn't return a value.

(rationale: there are other (uncommon) ways to write functions that don't return a value, there are also other uses for void, hence _primarily_, though your text wouldn't leave much questions either, I'm happy with whichever you choose)

[pkulikov]

@abelbraaksma thanks! I would use active voice in the final version:

void is a special built-in type. Typically, you use it as the return type of a method to indicate that the method doesn't return a value.

@BillWagner what do you think? If you agree, I'll submit a PR.

[svick]

Even though System.Void is a Type in .Net and unit is a type in F#, void is not a type according to the C# specification. And I think the documentation of C# should follow the terminology of the specification.

Some parts of the discussion at https://github.com/dotnet/roslyn/issues/16191 may be of interest here, e.g. where Neal Gafter says:

void isn't a type.

(Though most of that discussion is about the Roslyn API, which is irrelevant here.)

[abelbraaksma]

And I think the documentation of C# should follow the terminology of the specification.

@svick, the spec mentions that void is a type that represents the absence of a type. And as mentioned above, translates to a an actual type when used with typeof or when found through reflection. It's not a regular type, for sure (it's an empty struct, in fact), but it can be used in discovery. Since it's built in, we've argued it belongs on that page, with a note that it can only be used to indicate absence of a type.

From Roslyn's perspective, this may be slightly different, but this is from C#'s perspective. And Roslyn will get to see the real type System.Void whenever it's used with typeof (other languages may have different ways).

Trying to use void or System.Void directly to indicate the type of a variable or other argument than the return value of a function, is not possible. In that sense it lives up to its name that it represents the "absence of a type", but that doesn't make it any less a type.

@pkulikov, I agree with that text, looks good to me.

[BillWagner]

I agree with a note and referencing the article dedicated to void. I'll suggest this alternative wording:

The void keyword represents the absence of a type. You use it as the return type of a method that doesn't return a value.

Neal makes a lot of good points for not implying or stating that void is a type. As I mentioned earlier, the Types section of the standard does not reference void. The grammar for the typeof operator contains a special rule for void. Many other locations refer to a type, but do not include a special rule for void, generic type arguments being the first that comes to mind. Claiming that void is a type would require changing all those locations.

FWIW, hindsight does make us question the original decision that void isn't a type, but a special keyword. That decision was baked into the first version of the standard, and changing it now would be a large breaking change with minimal upside.

[abelbraaksma]

@BillWagner, I just browsed a few C# books to see what wording they use, and they're not consistent. Some use phrases like "the void return type", others say something along the line "use void if the method does not return a value". _Essential C#_ goes furthest in explaining what it is (yeah, I'm old fashioned, a physical book, really :P):

While theoretically "a type that represents the absence of a type" is still a type, at least I like to think so, I understand your viewpoint that changing all docs to reflect that is not worth the effort.

I'm ok with the proposed wording.

[abelbraaksma]

(interesting, on mobile the picture is shown sideways on github, but on desktop it is shown straight. Odd.)