[Suggestion] CNext: Respond with string for Task<string> Commands
See original GitHub issueSummary
Just a suggestion: Make Task<string> respond with the string returned. I don’t want to touch cnext and get sniped by emzi for breaking that (it’s Emziware)
Details
[Command("reply")]
public async Task<string> ReplyAsync(CommandContext ctx)
{
return "Hello World!";
}
and the bot should respond with Hello World!
Notes
I don’t want to get killed by Emzi for touching cnext or adding stuff to CNext without discussing
Issue Analytics
- State:
- Created 6 years ago
- Reactions:3
- Comments:8 (8 by maintainers)
Top Results From Across the Web
How to get returned value of async Task<string> method ...
1 Answer 1 ... Currently you're just calling Wait() - that will block until the task completes, but won't give you the return...
Read more >How do I immediately return a result from a task
In a base class, I am trying to create a default implementation for a function returning Task<string> . I can work out how...
Read more >How to Return a Value from a Task in C# with Examples
In this article, I am going to discuss How to return a Value from a Task in C# with Examples. Using the generic...
Read more >Consuming the Task-based Asynchronous Pattern
Learn to consume the Task-based Asynchronous Pattern (TAP) when working with asynchronous operations.
Read more >Tasks in Swift explained with code examples
Tasks in Swift allow us to create an environment in which we can run async methods using await. Learn how to create and...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
This is one of the things I considered and rejected early on. Adds unnecessary complexity. If anything, I’d use the return types to perhaps indicate a condition other than success, but even then, added complexity for no gain at all.
There’s also the performance aspect. This would cause a significant performance hit to command registration code, possibly command invocation code, and with coming changes to CNext, it’d make the whole CNext codebase extremely hard to debug, test, and maintain.