This repository has been archived by the owner on Oct 22, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 87
Remove IterableExtensions that have exact equivalents in the SDK #331
Closed
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will HAVE to be a breaking change (v2.0.0) since we are removing things.
Better to have a deprecation release first!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these are deprecated, it is impossible to switch to the non-deprecated version. You can't switch from
.firstOrNull
to.firstOrNull
.A removal is fully seamless, on the other hand. Could you check the internal discussion that I CC'd you on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh! I guess as long as the SDK constraint is correct.
I think we'll still need a breaking change version, though. @natebosch ? @devoncarew ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably true for the vast majority of code. Code with
import 'dart:core' as core;
can have trouble here, but that's pretty rare outside of generated code, and most also have an unprefixedimport 'dart:core';
.We could consider exporting the
dart:core
extension here. That should keep it non-breaking for even the edge cases. I think the analyzer will still have a diagnostic - but it might switch from unused import to "all used symbols from this import are also available from another import".WDYT @lrhn
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to not export the extension from
dart:core
.We can, but I don't think it'll ever bring us anything but headache.
And do it in a major version increment release, just to be technically allowed to be breaking, even if we hope that nobody notices.
It's not entirely non-breaking, even if we expose extensions with the same signatures,
on
types and name.If someone uses
show
orhide
ofIterableExtension
for a reason, or use explicit extension invocation, then it can break when that extension no longer has the members.Unlikely, not impossible.
At least we dodge the bullet of having the extension names themeslves conflict, because this one is called
IterableExtension
and the one indart:collection
is calledIterableExtensions
.So we could export it. But let's not take that kind of chances.
(And thank deity for lack of consistency.)