RFC: inject `Future[T]` automatically about nim-chronos HOT 7 OPEN

This is very bad idea, because all the implicit conversions of target procedure arguments or return value can create confusion when reading compiler's errors.

Compiler will show you types which was converted by "macro code", while you do not see this conversion in your source.

For example:
proc a(): int {.async.} got transformed implicitly to proc a(): Future[int] and now all compiler errors will be about Future[int] value, but not about int.

So current small inconvenience will become much more annoying. As an alternative we can remove silent conversion of procedures without return values to Future[void] and show an error.

from nim-chronos.

compiler errors

isn't this something that the macro could help with? basically, could it output did you forget "await"? in the right places?

if the objective of async/await is to make async code look like sync code (which most async frameworks seem to want to do), then decorating things with Future works against that goal - specially if you want to introduce other types like tuple and Option, it quickly gets very noisy - things that you would "naturally" do in sync code become very verbose.

from nim-chronos.

I support this change. The same question was discussed in a Nim RFC and someone correctly pointed out that you cannot avoid the type discrepancy - it will be either present in eyes of the caller or in the eyes of the implementer:

proc foo(): Future[int] {.async.} =
  result = 10 # How come the result is not a `Future`? That's what the signature says!

In the end, Nim has code generation features and we must learn to accept that. What this means it that when you start using a library, your first step should be to read the published documentation. You have to be aware that certain features such as custom pragmas may affect the generated code and you must develop the Nim survival skills to deal with this. I can promise you that the tools at your disposal will become better in the future.

There is a particular objective measure that gets improved with this change. It reduces the erroneous "degrees of freedom" of the API. It's no longer possible to produce certain compilation errors (oh, I forgot to add the Future type).

from nim-chronos.

Its very easy to remove all this result replacements and force people to use complete and fail explicitly. And i really like such change, but i really dislike proposal to perform implicit conversions and produce many nonsense compile time errors, because compiler will start mention Future[T] but you will not see Future[T] in your procedures and so for you this errors messages will have no sense.

from nim-chronos.

@arnetheduck because async macro is untyped we can't get type information, and becasue we do not have type information its very hard to show meaningful error. And we are not talking here about await in right places we are talking about modification of procedure's return value.

from nim-chronos.

how hard would it be to introduce an experimental macro that does this (async2 or whatever)? ie to play around with the syntax without committing to it..

from nim-chronos.

@arnetheduck all the logic of result value happens here in asyncmacro2.asyncSingleProc.

This part is responsible for verification of return value:
https://github.com/status-im/nim-chronos/blob/master/chronos/asyncmacro2.nim#L164-L181
This part is responsible for creation of internal result Future[T] object.
https://github.com/status-im/nim-chronos/blob/master/chronos/asyncmacro2.nim#L187-L193
And last transformation which transforms proc foo() {.async.} => proc foo(): Future[void].
https://github.com/status-im/nim-chronos/blob/master/chronos/asyncmacro2.nim#L255-L259

from nim-chronos.