Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: remove async await bind from task {}? #154

Closed
forki opened this Issue Nov 26, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@forki
Copy link
Contributor

forki commented Nov 26, 2017

While it's convenient that let! inside task {} works against async it still hurts type inference and error reporting. I'd vote for to remove that overload and let people explicitly use Async.StartAsTask

@gerardtoconnor

This comment has been minimized.

Copy link
Member

gerardtoconnor commented Nov 29, 2017

This was a requested addition from number of users, can you confirm what examples/scenarios are causing the TI issues as the bind overload should not conflict with Task overloads or statically resolved task-like overloads but I know TI on CEs always crop up so would be good to investigate as there are options like moving the bind to an extension method that should help inference resolution

@forki

This comment has been minimized.

Copy link
Contributor Author

forki commented Nov 29, 2017

the problem is not the conflict, but that type inference is not working properly:

image

where is c coming from? This leads to annoying things like the follwoing everywhere:

image

or wrong error reporting:

image

@gerardtoconnor

This comment has been minimized.

Copy link
Member

gerardtoconnor commented Nov 29, 2017

Due to the SRTP for task-like binding, we will still have TI unable to propagate up to a message signature automatically

There may be a bizarre way around this and still maintain inference if we go fully task-like in binding such that the inferred async object would be required to have constraints ... and we extend Async to include those constraints (it may be sealed so extension methods may not work, would be a PR to FSharp.Core).

Further to the above, we could even extend the AsyncState steps to include a AwaitAsync such that it would then be native continuation and not rescheduling?

Another option would be to SRTP bind the members of Async into Step also to avoid updating core ... but I think the inclusion of compatibility for task-like methods may help everyone for interop going forward?

@forki

This comment has been minimized.

Copy link
Contributor Author

forki commented Nov 29, 2017

@gerardtoconnor gerardtoconnor added the bug label Jan 5, 2018

@dustinmoris

This comment has been minimized.

Copy link
Member

dustinmoris commented Feb 9, 2018

Type inference issues should be fixed now with the latest version of TaskBuilder.fs.

@dustinmoris dustinmoris closed this Feb 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.