This repository has been archived by the owner on Oct 22, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sorry for the second PR in a row. This is part of the continuing effort to eliminate fuzzy arrows: dart-lang/sdk#29630 .
This PR isn't required for the effort, but it is intended to make the API friendlier to typed code, so that fewer changes are required in user code. I noticed when working on other code that calls to
predicate
cause frequent error messages about fuzzy arrows. The only two API facing changes are topredicate
andpairWiseCompare
. In both cases, I am proposing to make those functions generic, so that their function argument can be typed precisely. This is so that code that looks like:will be strong mode clean, instead of having to be written as:
or made fully dynamic.
I'm not sure whether this is considered a breaking change in the API or not - I believe that all existing non-strong mode code should be unaffected. Strong mode code that uses
--no-implicit-dynamic
could potentially get new errors.In passing, I noticed a fair bit of internal code which is more dynamic than it needed to be (and hence which will be slow on DDC). I made a number of passing changes to enable promotion to kick in so that the code is more statically typed. All of these changes are intended to be semantics preserving.