search

dart-lang / collection

The collection package for Dart contains a number of separate libraries with utility functions and classes that makes working with collections easier.
https://pub.dev/packages/collection
BSD 3-Clause "New" or "Revised" License
372 stars 86 forks source link

Remove IterableExtensions that have exact equivalents in the SDK #331

Open oprypin opened 7 months ago

oprypin commented 7 months ago

Since Dart 3.0, these extensions are in the SDK, exported from core: firstOrNull, lastOrNull, singleOrNull, elementAtOrNull

This package already bumped the version to be above that. So, the deletion will not cause any breakage to users, only potential "unused import" warnings.

Contribution guidelines:
- See our [contributor guide](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md) for general expectations for PRs. - Larger or significant changes should be discussed in an issue before creating a PR. - Contributions to our repos should follow the [Dart style guide](https://dart.dev/guides/language/effective-dart) and use `dart format`. - Most changes should add an entry to the changelog and may need to [rev the pubspec package version](https://github.com/dart-lang/sdk/wiki/External-Package-Maintenance#making-a-change). - Changes to packages require [corresponding tests](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md#Testing). Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.
devoncarew commented 5 months ago

I'm more hesitant on the major version rev - to 2.0.0 - then any other aspect of this change. I'm assuming everything - flutter (https://github.com/flutter/flutter/blob/master/packages/flutter/pubspec.yaml#L14) on up - will have to extend their version range to support this new version of collection. We may want to estimate the potential problems + costs in a specific issue.

oprypin commented 5 months ago

Thanks @devoncarew . I don't have an opinion on that, I only added the version bump upon request. The details regarding the version bump itself indeed have not been analyzed, and I'm not well equipped to take up that task.

At least I think we're in agreement regarding the rest of the change itself and that it should be done in this way, not some other way. And the details of how the change may be breaking were sufficiently discussed. The conclusion being, yes it's clearly breaking even though almost all code will continue to be buildable.

kevmoo commented 3 months ago

Slow down on this @oprypin – until we get the deprecation release out!

oprypin commented 3 months ago

I'm not doing anything, just updated the branch.

Note just to make sure we're on the same page: it is infeasible to deprecate firstOrNull and others in this PR, they will have to be directly removed, or just not removed.

kevmoo commented 3 months ago

@oprypin – oh wait! yeah you're doing it right!

You'll need to rebase again after publish, but we'll be good! 🙏

lrhn commented 3 months ago

Better to have a deprecation release first!

We should probably add the deprecations to the branch of the last released version, and make a new patch-version-increment release with the deprecations. Just to get them out soon.

natebosch commented 2 months ago

Better to have a deprecation release first!

We should probably add the deprecations to the branch of the last released version, and make a new patch-version-increment release with the deprecations. Just to get them out soon.

This is the technically correct thing to do, but it will cause significantly more churn for the ecosystem than the alternatives.

If we add a @Deprecated it will add (non-fatal) IDE noise for every existing use of these methods. The workarounds to hide this diagnostic noise are ugly and unintuitive. Any workarounds to hide the diagnostic will need a second step to back them out once we publish package:collection with the methods fully removed.

If we jump straight to removal the audience impacted is significantly smaller. Only unexpected edge cases. The impact is more severe, because it can cause a static error. The initial recourse is the long term fix, so no workaround to back out.

If we export (and maybe @Deprecate the export) the audience impacted is also very small, also only unexpected edge cases. The initial recourse could be the long term fix, but unless we automate that some authors might choose workarounds that would later need to be backed out.