3 ms·
I don’t agree with this analysis TBH - async drop has been revisited multiple times recently with no luck. Without a clear path there I don’t know why that woul
by anp 6y ago
I don’t agree with this analysis TBH - async drop has been revisited multiple times recently with no luck. Without a clear path there I don’t know why that would seem like an option for async/await two years ago. Do you actually think the language team should have completely exhausted that option in order to try to require an allocator for async/await?
Async drop would still not address the single-allocation-per-state-machine advantage of the current design that you’ve mostly not engaged with in this thread.
- newpavlov 6y ago>I don’t agree with this analysis TBH No worries, I like when someone disagrees with me and argues his or her position well, since it's a chance for me to learn. >async drop has been revisited multiple times recently with no luck The key word is "recently", meaning "after the stabilization". It's exactly my point: this problem was not sufficiently explored in my opinion prior stabilization. I would've been fine with a well argued position "async Drop is impossible without breaking language changes, so we will not care about it", but now we try to shoehorn async Drop on top of the stabilized feature. >Async drop would still not address the single-allocation-per-state-machine advantage of the current design that you’ve mostly not engaged with in this thread. I don't think you are correct here, please see this comment: https://news.ycombinator.com/item?id=26408524 https://news.ycombinator.com/item?id=26408524