Consider removing "Async" suffixed from generated commands

[taori]

Naming methods "METHODNAMEAsync" is a common naming convention for methods. I think the code generator should not name the commands with the async suffix too, since that is just sort of redundant

[Sergio0694]

But... It already does 🤔

Do you have a minimal repro where that is not working for you?

[taori]

8.0.0-Build.138

[Sergio0694]

I would say that's by design to push people to use async Task and not async void for commands (and in general) 😄

[taori]

Hm, while i am inclined to insist that is a bug, i agree too much about discouraging people from using async void, because in most cases where people are not aware of the implications of async void it just introduces hard to find bugs

[Sergio0694]

"while i am inclined to insist that is a bug"

I mean it's not a bug, we're explicitly only checking this if the method returns a Task 😄

dotnet/CommunityToolkit.Mvvm.SourceGenerators/Input/ICommandGenerator.Execute.cs

Lines 352 to 357 in f3bd3d8

	if (methodSymbol.Name.EndsWith("Async") &&
	(methodSymbol.ReturnType.HasFullyQualifiedName("global::System.Threading.Tasks.Task") ||
	methodSymbol.ReturnType.InheritsFromFullyQualifiedName("global::System.Threading.Tasks.Task")))
	{
	propertyName = propertyName.Substring(0, propertyName.Length - "Async".Length);
	}

[taori]

A bug in terms of naming guidelines, not a code bug in terms of behavior, yeah. Definitely true. I'll drop it since i agree on your motived either way :)

[Sergio0694]

I mean you do make a good point, it would be nice to still give users some better info here. We can't do this for 8.0.0 since we're feature-locked for that now, but I'm thinking we might look into adding some more analyzers with some warnings or whatnot for post 8.0.0. For instance, here we could show a warning suggesting to change the method to return a Task, instead of just ignoring it.