-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[breaking change] Mark four more classes in dart:async
as interface
#52334
Comments
SGTM! |
fine by me |
LGTM |
Ping. |
lgtm |
dart:async
as interface
dart:async
as interface
Change has landed and cherry-pick to stable has landed too. |
It seems like this change request has never been posted to [email protected] (I can't find in the archives FWIW) - if that's not supposed to be a reliable source for breaking change requests, is there another channel to subscribe? This breaks one of my packages with quite a few dependents (including packages maintained by the Dart team!). So it would have been nice to know about this a couple months ago 🙃 |
Change Intent
Mark interface classes as
interface
, for consistency with other similar classes.The
StreamConsumer
,StreamIterator
,StreamTransformer
andMultiStreamController
classes fromdart:async
areabstract
classes with only abstract members.As such, for consistency and showing intent, they should have been made
abstract interface
declarations like other similar classes.Justification
The classes were missed in the initial marking with modifiers, for some reason. (Likely oversight, they're all far down in a very long file. Mea culpa.)
It would be consistent with other similar classes to mark them as
interface
, and it would express the intent of the class.It's not a necessary change. We can keep them as-is, but it's inconsistent, and will only become harder to fix if we wait.
Impact
Low impact. Two known occurrences of
extends StreamConsumer
in packages (one of them is our own package, which we can quickly change), and we can propose a patch before they have a chance to release a 3.0 compatible version of the package.Because the changed library is a platform library, the change will not affect pre-3.0 libraries at all!
If released in Dart 3.0.1, we can should keep the window for someone adding a new
extends OneOfTheseInterfaces
dependency and releasing it with a 3.0.0 language version, very small.Mitigation
It's not breaking to code existing before today, but it may (hypothetically) break code released between today (3.0 launch) and when the change is released (hopefully 3.0.1).
There are two known non-SDK uses which extends these classes (based on searching internal use), in packages
http_server
andstreams
.http_server
package is discontinued and archived, so it will never have a 3.0 language release.streams
package (flutter_stream_extensions
) usage is only in a test, so even if they release a 3.0 version, it won't break users, and the developers can take a patch to fix it at any time. It seem to be developed inside Google, so maybe I can fix it directly.The text was updated successfully, but these errors were encountered: