Remove IterableExtensions that have exact equivalents in the SDK

[oprypin]

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.

• Closes Deprecate IterableExtensions that have exact equivalents in the SDK dart-lang/core#671

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide 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 and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[kevmoo]

This will HAVE to be a breaking change (v2.0.0) since we are removing things.

Better to have a deprecation release first!

[oprypin]

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

[kevmoo]

Oh! I guess as long as the SDK constraint is correct.

I think we'll still need a breaking change version, though. @natebosch ? @devoncarew ?

[natebosch]

A removal is fully seamless, on the other hand

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 unprefixed import '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

[lrhn]

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 or hide of IterableExtension 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 in dart:collection is called IterableExtensions.
So we could export it. But let's not take that kind of chances.
(And thank deity for lack of consistency.)

[devoncarew]

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]

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]

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

[oprypin]

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]

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

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

[lrhn]

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]

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.

[mosuem]

Closing as the dart-lang/collection repository is merged into the dart-lang/core monorepo. Please re-open this PR there!