Skip to content
This repository was archived by the owner on Oct 23, 2024. It is now read-only.

Tighten type for argument to evaluate #22

Merged
merged 4 commits into from
Jan 24, 2020
Merged

Tighten type for argument to evaluate #22

merged 4 commits into from
Jan 24, 2020

Conversation

natebosch
Copy link
Contributor

Taking a dynamic throws away the static help that a caller would get
with an argument type. Since it is easy to refactor callers currently
passing an Iterable<String> to tear off the .contains method we can
take the Function type always. This also improves inference for argument
types in places that are passing a function literal.

Taking a `dynamic` throws away the static help that a caller would get
with an argument type. Since it is easy to refactor callers currently
passing an `Iterable<String>` to tear off the `.contains` method we can
take the Function type always. This also improves inference for argument
types in places that are passing a function literal.
@natebosch
Copy link
Contributor Author

Filing for discussion. The only known usage is in test, and those usages are fixed in dart-lang/test#1125

We may also want to punt on this until we do the null safety migration since that will also end up requiring a breaking change version bump and we can roll this in with that to reduce churn.

Copy link
Contributor

@jakemac53 jakemac53 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@natebosch
Copy link
Contributor Author

After discussion we're going to go forward with this since the impact is so minimal - only the test packages use this and we can easily update deps.

@natebosch natebosch merged commit 1309eab into master Jan 24, 2020
@natebosch natebosch deleted the evaluate-strict branch January 24, 2020 00:41
mosuem pushed a commit to dart-lang/tools that referenced this pull request Oct 18, 2024
…r#22)

Taking a `dynamic` throws away the static help that a caller would get
with an argument type. Since it is easy to refactor callers currently
passing an `Iterable<String>` to tear off the `.contains` method we can
take the Function type always. This also improves inference for argument
types in places that are passing a function literal.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants