Slava Egorov
Slava Egorov
I have some concerns about performance / code size implications associated with this mechanism as it is proposed: there is an invisible cost (both in terms of performance and code...
> However, I'd like to highlight an inconsistency that arises due to Dart's transpilation into different languages across platforms. > > For instance, Dart's compilation to C++ for the Windows...
> That's a frame where if we didn't use async/await, we could've gotten the value already. That has nothing to do with `await` though. You will see exactly the same...
> (similar to how asynchronous functions in JS are mapped to Dart asynchronous functions) I don't think we actually have this. Do we? There is no automatic conversion between `Future`...
> Won't it then be possible to have some Dart implementation for this that extends/implements `Iterable` that would be a suitable wrapper for the JS `Generator` iterator type? Then similar...
I will go on record and say that these summaries are useless noise which I simply learned to filter out. I never look at them now. I would honestly prefer...
Fixed by #1401
cc @aam @mkustermann
@leafpetersen > @mraleph I think I could get comfortable with this if it was made more explicit that this is not intended to be a way to run arbitrary Dart...
On the topic of AOT compiling our tools: ``` $ tools/test.py -c dart2analyzer --use-sdk co19/Language ... [01:20 | 100% | +20451 | - 96] === 20451 tests passed, 96 failed...