Proposal: allow void keyword as parameter for methods and lambdas

[lachbaer]

Allowing the void keyword as lambda parameter would allow for

var t = Task.Run(void => 
        {  Console.WriteLine("Task thread ID: {0}",
           Thread.CurrentThread.ManagedThreadId);
        } );

This should also be allowed for parenthesized parameters for a consistent look and feel.

void AMethod(void) { }
var t = Task.Run( (void) => {} );

Introducing this syntax extension could make the definition of anonymous methods with the delegate keyword 'deprecated'.

Needless to say that void must be the only parameter and without identifier name. Otherwise it wouldn't make sense.

[JoeStead]

I may be missing something fundamental here, but how does your code differ from the following?

var t = Task.Run(() =>
{
    Console.WriteLine($"Task Thread Id {Thread.CurrentThread.ManagedThreadId}");
});

[lachbaer]

@JoeStead
(() => vs. void => ;-) better readability
There's a comment in #8594 mentioning the wish of @jaredpar and @agocke to 'ignore parameter list' for lambdas, in order to deprecate the delegate anonymous functions.

[svick]

@lachbaer

If void is supposed to ignore the parameter list the way e.g. delegate {} does, then I think void is a pretty confusing choice, because it would mean void does not mean that the parameter list is actually empty.

If it's supposed to be just alternative syntax for () =>, then I don't think it improves readability, especially since having two different syntaxes for exactly the same thing is confusing.

[lachbaer]

@svick void acutally means "nothing" (in a way) and this kind of syntax is just taken from C/C++.

In C:
void foo() means "a function foo taking an unspecified number of arguments of unspecified type"
void foo(void) means "a function foo taking no arguments"

In C++:
void foo() means "a function foo taking no arguments"
void foo(void) means "a function foo taking no arguments"

(from http://stackoverflow.com/questions/51032/is-there-a-difference-between-foovoid-and-foo-in-c-or-c)

From what I read in the comment of the pull request stated above, I think that the language design team wants to get rid of the delegate syntax.

[lachbaer]

@svick

If it's supposed to be just alternative syntax for () =>, then I don't think it improves readability, especially since having two different syntaxes for exactly the same thing is confusing.

With this addition you won't have different syntaxes, because

() => noop();
// is the same as
(void) => noop();
// is the same as
void => noop();

/* nearly equivalent to the example */
(type x) => x as type;
x => x as type;

With the upcoming pattern matching just specifying the type without an identifier, e.g. (int), will be common. (void) would fit in here, optically, as it states a 'type' without an identifier.

[alrz]

I'd like to suggest to use capture list (#177) syntax (alone) for that matter,

// currently
Action      action = delegate() {};
Action<int> action = delegate(int arg) {};

Action      action = delegate {};
Action<int> action = delegate {};

// capture lists
Action      action = []() => {};
Action<int> action = [](arg) => {};

// so
Action      action = [] => {};
Action<int> action = [] => {};

void F(Action      action) {}
void F(Action<int> action) {}
void G(Action<int> action) {}

F(delegate {}); // ERROR
F([] => {});    // ERROR

G(delegate {}); // OK
G([] => {});    // OK

[lachbaer]

@alrz Though that is a valid suggestion, I think that a simple void is

1. better to read than []()
2. much better to write (e.g. I have a German keyboard layout, that is awful for brackets, braces, etc.)
3. can just be an alias for it

After reading #117 I think what the comment of the developers actually meant by saying "ignore parameter list" ;-) Nevertheless I for myself like the use of the void keyword for marking reasons.

E.g. I also don't really like that methods and properties sometimes are only differentiated by () on the first line. When property scoped fields will be available then maybe even a few lines of code. (void) would just make it better distiguishable to properties.

[alrz]

@lachbaer Unfortunately, it's C#. Every single character counts. 😱

If you are arguing that it "can just be an alias for it" and it's "better to read" I think delegate {} syntax already fits. The point is that a lambda expression is more concise than delegate or your proposal void, otherwise there is no point to not use delegate and void makes no difference.

[lachbaer]

Also, if the team decides to implement the "ignore parameters feature", the void keyword in this context would easily allow to start implementing it. Adding the capture list feature possibly could be done after that, having already 'prepared' some of its necessary requirements - maybe.

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I am not moving this particular issue because I don't have confidence that the LDM would likely consider doing this.