[Proposal] C# Feature Support Omitted Keyword "void" In Function Declaration

[Aumeeb]

FEATURE_NAME

Omitted Keyword Void

Summary

Improve development speed, and reduce extra code to do the same functionality.

Motivation

public class AnimPast : MonoBehaviour
{
   private void Attack(){}
   private void Idle(){}
   private void Run(){}
}
public class AnimPresent : MonoBehaviour
{
   void Attack(){}
   void Idle(){}
   void Run(){}
}
public class AnimFuture : MonoBehaviour
{
   Attack(){}
   Idle(){}
   Run(){}
}

Why are we doing this?

Benefits

1. Reduce code size
   
2. Easy to read
3. Half of functions in the entire project is return "void", think about how much time cost on write the keyword "void" and remove them later.
4. It provides more readable space for split screen feature.
   
5. More environmentally friendly. Although the price of hard disks is already very cheap, a void + a space takes up 5 bytes. I found that there are more than 260 such structures in my project. This disk waste can be optimized. Think about the entire C# ecosystem.

What use cases does it support?

1. Entire projects and all programmers.

What is the expected outcome?

1. Implement same outcome as the original function taking the keyword "void".

Detailed design

If a function declaration without keyword "void", it regards as return "void", the compiler able to detect this situation such as Omitted keyword "private"(I thought).

Drawbacks

Can't compatible with low version C# , or give users a hit, to use this feature your C# version must be higher than C# 13?🤔

[KennethHoff]

There are no practical time loss from omitting the keyword void. If you're a slow typer that's still only a second saved at most.

90+% of time spent is _reading _ code, therefore we should optimize for that instead, and personally I do not think omitting the return type makes anything more readable.

Also, how often do you realistically use void? I'm imagining at most 10% of my Methods are void "returning".

While there's still a fair amount of ceremony in C# (it is quite good nowadays however), this ain't it.

[siegfriedpammer]

I'd say it's even less than a second. I think OP spent a lot more time to write this proposal than it would save the average developer in a year. If we include the time to actually properly spec, implement and test this in all involved components of the ecosystem it's even worse.

[Aumeeb]

If there are 100 void functions in a project, then at least 100 seconds are saved. If it is scaled up to the entire C# ecosystem, it is immeasurable.

I agree that most of the time is spent reading code. There is a thinking habit here. When you see void, it means that there is no return value. But doesn’t the existence of a useless void also mean that there is no return value?

This principle is the same as omitting the private keyword. You can choose to add private or omit it.

When comparing code names and displaying the code on a split screen, an additional void keyword will cause the subsequent function names to be unreadable. This is also a problem. In short, the void is for readers to see. How can C# use this feature in version 1.0? , do you think it is necessary to add one more void keyword?🤔🤔🤔

[Aumeeb]

My main point is that if the keyword tells the reader that this function has no return value, then if void is not added, it doesn't mean that the function has no return value. Assuming that the reader can understand it without adding the void keyword, then why not Omit the void for simplicity?🤣🤣🤣

[CyrusNajmabadi]

A challenge here is simply that this would make constructors and methods syntactically ambitious.

The syntax you have here is exactly the Syntax for constructors. We would not be able to effectively parse this in a context free fashion.

We'd have to parse all of these as constructors or all of these as methods. Both would break existing consumers of our apis.

Def something I would be wary of.

[Aumeeb]

I don't know much about the underlying syntax parsing. It may be easy for users to use, but it is very difficult to implement technically.🤣🤣🤣
Yes, this syntax is same as constructor syntax. to distinguish them, the constructor function must match the class name, the omitted void function name that can't match the class name.

[CyrusNajmabadi]

the constructor function must match the class name, the omitted void function name that can't match the class name.

Right. But a grammar can't express that. And the parser doesn't know that, since it wants the parsing to be context free.

It would also break incremental parsing. Today, if you change the name of a type, all the members can be reused (because there is no contextual relationship between the two). Now the parsing is context sensitive, so you can't incrementally parse a type (since the type of the node might change).

Alternatively, you parse all constructors as methods. But that breaks a ton of code that expect to get ConstructorDeclaration nodes.

[The-Futurist]

I suspect the reason there even is void (in C) was for ease of parsing, if all invocable code definitions have the same syntactic structure then it is easier to write a parser and so having void solves the problem for invocable code that is not a true function despite the fact it is not a function it is made to "look like" one. I understand what you're saying and it makes a lot of sense but C's grammar never really was designed to leverage some of the language design ideas that had emerged in the late 1960s, it basically ignored these ideas and became what it is today, likewise all those languages that have chosen C as their grammatical basis.

Bear in mind too, language design back then was pretty challenging anyway, the tools were few and far between and the expertise in the field was scarce, the C designers did a good job given the facilities available to them and their overall goal of writing an OS.

[CyrusNajmabadi]

@Korporal there is no conern about C here, and digressions about its choices don't really have any bearing or value on the discussion for us.

From C#'s perspective, tehre is no issue grammatically with this. The only question we have to answer is: Is this actually something we want people to be able to do?

If we decide that the answer is 'yes', then updating our grammar and impl to support this is trivial. If we decide the answer is 'no', we'll simply keep the status quo.

but C's grammar never really was designed

C's grammar is irrelevant here. Their decisions to not impact the choices we make for ours. The only aspect that matters here is if we think it's a good thing or not for people to be able to create void methods without stating void. Personally, i see the value. But it's so marginal that i wouldn't champion this.

likewise all those languages that have chosen C as their grammatical basis.

None of that is relevant here. There's no aspect of C# that says "C doesn't allow, so we won't".

the C designers did a good job given the facilities available to them and their overall goal of writing an OS.

Similarly not relevant. Their language, choices, and stewardship of their ecosystem have literally zero bearing on. We literally do not consider it or look to it when making our own choices wrt to the future of the language.

Please keep the conversation on topic to what is being discussed here. Namely, allowing 'void' to be dropped in C#.

[jnm2]

There's usually a sweet spot. Past that point, shorter means less easy to understand. Seeing familiar patterns speeds up the understanding, similar to painted lines on a road when driving. Ambiguity is expensive.

[IS4Code]

This would not work well with local functions:

void M() { do stuff; } // a local function M

M() { do stuff; } // same, with this proposal

M(); { do stuff; } // a call to M followed by a block

[The-Futurist]

This is common to C, C++, Java and several other languages who's grammar is based on C. I doubt that the void type on functions can be eliminated without breaking existing source code. C# is a great language but it's choice of grammar has never done it full credit - IMHO.

[CyrusNajmabadi]

This is common to C, C++, Java and several other languages who's grammar is based on C. I doubt that the void type on functions can be eliminated without breaking existing source code. C# is a great language but it's choice of grammar has never done it full credit - IMHO.

This could be done without breaking existing code. The above examples are not legal c#, and it's fine to make currently illegal c# legal.

The only area where there is an issue is with parsing. This would make parsing slightly more contextual. Not a deal breaker, just additional complexity to consider.

[The-Futurist]

@Aumeeb

Related to this is the possibility of removing empty parentheses on functions that take no arguments.

so something like:

void ResetStatus()
{
}

could become

ResetStatus
{
}

If eliminating the void can (in principle) be done without breaking existing source, then presumably removing empty parens can be treated similarly.

[CyrusNajmabadi]

The likely problem here is that this would look very similar to a property. The parens at the declaration-site mirror the parens needed at the callsite.

Note: this is not a claim that we could not technically do this. This is a claim that we should not do this because it would be confusing with an existing similar language construct.

[The-Futurist]

The parens at the declaration-site mirror the parens needed at the callsite.

They could be omitted at the callsite as well, since there are no args.

[CyrusNajmabadi]

They could be omitted at the callsite as well, since there are no args.

That already has meaning. It gives you the method instance as a delegate.

[CyrusNajmabadi]

We also have a perfectly good way of having members that take no args that can be declared and used without parens. They are properties :) It's intentional and desirable that the non-value (void) space of this is different.

[Aumeeb]

"()" means this is a function in most scenarios, they are easy to read, without "()" people usually think they are non-function code

[iam3yal]

In what world the reasons listed in the OP make sense? seriously. I almost thought it's April Fool's Day or something.

Improve development speed, and reduce extra code to do the same functionality.

Really? where are the numbers? because we don't use snippets. 🙉

Reduce code size

Size is important but this is ridiculous if you think this is what we need to optimize to reduce it.

I'm actually in the camp that prefers the example below over the two alternatives you gave above.

public class AnimPast : MonoBehaviour
{
   private void Attack(){}
   private void Idle(){}
   private void Run(){}
}

I like to waste space. 🙊

Easy to read

It's actually not, it makes it harder to read. Feels like reading a statement where you need to fill the empty gaps.

Half of functions in the entire project is return "void", think about how much time cost on write the keyword "void" and remove them later.

Yes, again, because you actually have to type that. 🙉

It provides more readable space for split screen feature.

Yes, this is absurd. Seriously. 🙈

Entire projects and all programmers.

All except many that like their code to be crystal clear.

[The-Futurist]

@iam3yal

The proposal is to eliminate the need for void as a "function" (which is not actually a function) return type, there are arguments for and arguments against. I'm generally in favor of a less clumsy, more elegant syntax than we see in C (and derivatives) but that's just me. There are many programming languages around and many do not express "nothing is returned" by a special keyword, they just don't put anything because there's nothing really to express, putting a special keyword to mean "this is not a function" is fine but there are other ways to express such ideas.

[iam3yal]

@Korporal

1. void does not mean that there is no type, it means that the method does not return a value.
2. There is a big difference between omitting important information and having succinct syntax.
3. Most programming languages that don't indicate the return type are either dynamic languages where the type is known at runtime or languages that have aggressive type inference and is optional but in both of these cases it still doesn't mean that "there is no type".
4. They don't put anything not because there is nothing to express but because it's defined and semantically possible.
5. In this proposal it's done for wrong reasons so imo it doesn't make a lot of sense to have it in C#.

[The-Futurist]

void does not mean that there is no type, it means that the method does not return a value.

A non existent value has no type does it?

Most programming languages that don't indicate the return type are either dynamic languages where the type is known at runtime or languages that have aggressive type inference

That's not true, consider for example Pascal and there are others. There's no possibility of inferring a type for something that does not exist.

In this proposal it's done for wrong reasons so imo it doesn't make a lot of sense to have it in C#.

Well your rebuttal is full of errors so I don't know how that impacts the validity of your conclusions.

Functions are distinct from procedures, like Func<T> is different from Action<T> I mean there is no Func<void> is there? No, there is not, instead we have Action . We should have no need for Action at all, everything should be expressible through Func but it is not, that's noteworthy. This should alert you to the fact that there is a subtle inconsistency in the argument that every invocable method is a "function" they are not and it does no good to pretend they are.

Why can't you use Func to define a void delegate? One should be able to, if the pattern you're insinuating had any merits.

[CyrusNajmabadi]

A non existent value has no type does it?

It has the unit type.

I mean there is no Func is there? No, there is not, instead we have Action

This was a runtime limitation. It was def something we could have made work. But time limits and expediency has us go this route. Unification here would have been nice, but it was better to be consistent with the choices that are 20 years old now versus changing things.

[iam3yal]

@Korporal

That's not true, consider for example Pascal and there are others. There's no possibility of inferring a type for something that does not exist.

I said most... not all and it certainly true for most languages.

Well your rebuttal is full of errors so I don't know how that impacts the validity of your conclusions.

A bit bitter, aren't we? it was an opinion... not a conclusion.

Functions are distinct from procedures, like Func is different from Action I mean there is no Func is there? No, there is not, instead we have Action . We should have no need for Action at all, everything should be expressible through Func but it is not, that's noteworthy. This should alert you to the fact that there is a subtle inconsistency in the argument that every invocable method is a "function" they are not and it does no good to pretend they are.

This has absolutely nothing to do with the discussion or what I wrote. 🤷‍♂️

[nathan130200]

An, what/how? Does anyone really have difficulty writing the keyword void? Is it really difficult? I think the OP forgot that void is not just a keyword, but a return type as well.

In fact, this will lead to serious conflicts between determining what is a function and what is an object constructor.

[The-Futurist]

An, what/how? Does anyone really have difficulty writing the keyword void? Is it really difficult? I think the OP forgot that void is not just a keyword, but a return type as well.

In fact, this will lead to serious conflicts between determining what is a function and what is an object constructor.

Well I heard the same kind of arguments from COBOL aficionados, they'd say stuff like "So really, does anyone really have a problem writing DIVISION? does anyone really have that much pain beginning their code in column 6?

[The-Futurist]

@nathan130200
I beg to differ, certainly on this point, one of linguistic redundancy. The void is redundant, a throwback to C (that is where it originated, the C# designers retained it, they did not originate it as some kind of innovation). Notice how C# dropped the use of void in this case:

void DoSomthing(void)
{
}

They dropped it (forbid it) in the case "there are no args" but retained it in the case of "there is no value returned". They did a very good job, I very much like C# and enjoy working with it, but these criticisms are not to be dismissed, they are legitimate criticisms.

[CyrusNajmabadi]

Right. As mentioned, we already had taken that syntax to mean something else.

[iam3yal]

@Korporal

1. We're not here to revolutionize the language.
2. You're saying that it's redundant when it's clearly not, it has a well defined meaning and it's not optional.
3. Maybe if they were designing C# 1.0 today, then maybe their decisions could have been different but this ship has sailed.
4. Maybe when they might add DUs to the language, depends on their design they may have a chance to do more in that area maybe even introduce new types, syntax, runtime changes? who knows.
5. I don't think the criticism is dismissed but changing it, doesn't really benefit the language or the ecosystem and it's really a nonissue.

I wouldn't presume to dictate people's programming methods, but rather than trying to change the language, perhaps optimizing your working environment to suit the kind of work you do would be more beneficial.

[CyrusNajmabadi]

Speaking for myself, if we were to do this again, i would not have used void as the syntax. But i also would not have made it optional. I would simply have had parity that "everything is an input/output function" and that the input/output is a single type.value. Void would normally be represented with the unit/unit-tuple type and value. And the inputs to functions would often be the same as well.

Regardless, this suggestion just does not seem worthwhile. It introduces problems and saves very little. The current approach is idiomatic and prevalent. I don't see value in investing here versus the thousands of other things people would want. There's a def absence of interest from the team currently, and i don't see people putting forth viable arguments that is realistically changing that equation.

[iam3yal]

@CyrusNajmabadi Exactly my thoughts.

[Aumeeb]

[HaloFour]

Typescript is a superset of Javascript, and all legal Javascript is legal Typescript. Not to mention, the type hints are all 100% optional. Typescript is a very different language with very different goals and is a not a good analogy to C#.

[CyrusNajmabadi]

This is also an incorrect understanding of typescipt (Source: was TS designer :)). Omitting the return type does not mean 'void', it means: "infer the return type from the contents of the function".

Here the return type is absolutely not void. It very much is number as far as typescript is concerned.