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.

• References Deprecate IterableExtensions that have exact equivalents in the SDK #330

---

• 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.