sdk
sdk copied to clipboard
[breaking change] Discontinue deprecated core library APIs, part II
The following Dart core library APIs, which are all currently deprecated, are now being fully removed.
This is the continuation of previous discontinuation work tracked in https://github.com/dart-lang/sdk/issues/34233
NOTE: This plan is tentative and not yet fully signed off.
Phase II, scheduled for Dart 3.0
The following APIs are planned to be removed in 3.0, as some breakage is to be expected.
dart:core
- [ ]
proxyconstant: https://dart-review.googlesource.com/c/sdk/+/258004 - [ ]
Provisionalclass and associated constant: https://dart-review.googlesource.com/c/sdk/+/258004 - [ ]
onErrorargument toint.parse: https://dart-review.googlesource.com/c/sdk/+/259042 - [ ]
IntegerDivisionByZeroExceptionexception (useUnsupportedError): https://github.com/dart-lang/sdk/issues/30743 - [ ]
Listconstructor (useList.Filled): https://dart-review.googlesource.com/c/sdk/+/258920 - [ ] Errors:
- [ ]
CastErrorclass (useTypeError): https://dart-review.googlesource.com/c/sdk/+/259041 - [ ]
AbstractClassInstantiationErrorclass (no longer relevant): https://dart-review.googlesource.com/c/sdk/+/259041 - [ ]
FallThroughErrorclass (Unused since Dart 2.0): https://dart-review.googlesource.com/c/sdk/+/259041 - [ ]
NoSuchMethodErrorexception (useNoSuchMethod.withInvocation): TODO
- [ ]
dart:async
- [ ]
DeferredLibraryclass - [ ]
runZoned'sonError: CL: https://dart-review.googlesource.com/c/sdk/+/248002
dart:developer
- [ ]
MAX_USER_TAGSinUserTag
dart:mirrors
None?
dart:html
- [ ] discontinue
document.registerElement®isterElement2in Dart 2.19
@sigmundch is the NoSuchMethodError constructor ready to be removed? There is a comment about dart2js here:
https://github.com/dart-lang/sdk/blob/main/sdk/lib/core/errors.dart#L492
Our dependency is still there, but probably can easily be refactored by updating the dart2js patch files without changing the compiler directly /cc @rakudrama
If we want to ship dart migrate in Dart 3.0, is it ok if that tool does not understand these removed APIs?
For example, if someone installs Dart 3.0, and uses that Dart's dart migrate to try to migrate code which refers to CastError, is it ok if dart migrate fails in some way? Crashes or something like that on the unresolved element.
FWIW, dart migrate is implemented in pkg/dartdev, which has a simple import of pkg/nnbd_migration. It does not currently shell out to a separate snapshot.
@mit-mit https://github.com/dart-lang/sdk/commit/efb509c114dcaf54d0a011f717b48893d71ec9c3 should address the dependency from dart2js, I think the constructor is now ready to be removed.
If we want to ship dart migrate in Dart 3.0, is it ok if that tool does not understand these removed APIs?
@srawlins I think that is OK. If a developer wants support for migrating away from discontinued APIs, they can use the 2.19 SDK.
@sigmundch @kevmoo is the comment above about the dart:html change accurate (i.e. we're removing that in 2.19)?
@mit-mit, can you clarify which comment are you referring to?
We landed changes to mark the APIs deprecated in late July. Those haven't been released yet in the stable channel, so it will first get broad visibility with the 2.19 stable release. Given that, we wont be removing it entirely in 2.19, but the release that follows.
@sigmundch I was looking at an older, stale version, sorry.
Given that, we wont be removing it entirely in 2.19, but the release that follows.
sgtm, we'll track that as a 3.0 removal then
AbstractClassInstantiationError class (no longer relevant)
The class may be irrelevant when running normal Dart code, but not when using mirrors:
https://github.com/dart-lang/sdk/blob/636232628bfb9f8aa1d8b16656d647c8c3cc2205/tests/lib/mirrors/instantiate_abstract_class_test.dart#L40-L44
Should classMirror.newInstance(decl.constructorName, args) start throwing a different type of exception, or should we move AbstractClassInstantiationError to dart:mirrors as per https://dart-review.googlesource.com/c/sdk/+/259041/16/sdk/lib/mirrors/mirrors.dart ? @mit-mit
The class may be irrelevant when running normal Dart code, but not when using mirrors:
The text was unclear. It's no longer relevant in the dart:core libraries. But, yes mirrors can still throw it, and now have their own definition of it: https://dart-review.googlesource.com/c/sdk/+/259041/16/sdk/lib/mirrors/mirrors.dart
@mit-mit Are you expecting there will be tracking issues for the removal of CyclicInitializationError and NullThrownError. Is there already discussion happening somewhere?
Those are expected to be removed next few days; CLs will be linked from the top comment.
All done, closing
hey @mit-mit you forgot MapEntry in your list which cannot be extends anymore (it breaks ClojureDart btw).
Making MapEntry a final class will, like all other now-final classes in the platform libraries, only affect code when it migrates to Dart 3.0.
It's not, technically, considered breaking, even though it prevents some uses from being continued. The existing code, running at language version 2.19, will keep working until support for pre-3.0 code is removed, which is unlikely to be soon.
The list of classes which have become final are (lifted directly from the source code):
dart:async
final class AsyncErrorfinal class DeferredLoadExceptionabstract final class ZoneSpecificationabstract final class ZoneDelegateabstract final class Zone
dart:collection
abstract final class HashMapabstract final class HashSetfinal class HasNextIteratorabstract final class LinkedHashMapabstract final class LinkedHashSetfinal class DoubleLinkedQueuefinal class ListQueuefinal class SplayTreeMapfinal class SplayTreeSet
dart:convert
final class AsciiCodecfinal class Base64Codecfinal class Base64Encoderfinal class Base64Decoderfinal class HtmlEscapeModefinal class HtmlEscapefinal class JsonCodecfinal class JsonEncoderfinal class JsonUtf8Encoderfinal class JsonDecoderfinal class Latin1Codecfinal class Latin1Encoderfinal class Latin1Decoderfinal class LineSplitterfinal class Utf8Codecfinal class Utf8Encoderfinal class Utf8Decoder
dart:core
abstract final class BigIntfinal class OutOfMemoryErrorfinal class StackOverflowErrorabstract final class Functionfinal class MapEntryfinal class Nullabstract final class Recordabstract final class Stringfinal class Expandoabstract final class WeakReferenceabstract final class Finalizer
dart:developer
abstract final class NativeRuntimefinal class ServiceExtensionResponseabstract final class UserTagfinal class ServiceProtocolInfofinal class Servicefinal class Flowabstract final class Timelinefinal class TimelineTask
dart:ffi
final class AbiSpecificIntegerMappingfinal class DartRepresentationOffinal class Unsizedfinal class Charfinal class SignedCharfinal class UnsignedCharfinal class Shortfinal class UnsignedShortfinal class Intfinal class UnsignedIntfinal class Longfinal class UnsignedLongfinal class LongLongfinal class UnsignedLongLongfinal class IntPtrfinal class UintPtrfinal class Sizefinal class WCharfinal class DynamicLibraryfinal class Pointerfinal class Arrayfinal class Dart_CObjectabstract final class NativeApifinal class FfiNativefinal class Nativefinal class DefaultAssetabstract final class NativeFinalizerabstract final class NativeTypefinal class Int8final class Int16final class Int32final class Int64final class Uint8final class Uint16final class Uint32final class Uint64final class Floatfinal class Doublefinal class Boolabstract final class Voidabstract final class Handleabstract final class NativeFunctionabstract final class VarArgsfinal class Packed
dart:io and dart:html
abstract final class HttpClientBasicCredentialsabstract final class HttpClientDigestCredentialsfinal class HttpProfiler
dart:io
abstract final class ZLibOptionfinal class ZLibCodecfinal class GZipCodecfinal class ZLibEncoderfinal class ZLibDecoderfinal class FileSystemEntityTypefinal class FileSystemEventfinal class FileSystemCreateEventfinal class FileSystemModifyEventfinal class FileSystemDeleteEventfinal class FileSystemMoveEventabstract final class Platformabstract final class ProcessInfofinal class ProcessStartModefinal class ProcessResultfinal class InternetAddressTypefinal class SocketDirectionfinal class SocketOptionfinal class RawSocketOptionfinal class ConnectionTaskfinal class Datagramfinal class SocketMessagefinal class StdioTypefinal class SystemEncoding
dart:isolate
final class Isolatefinal class RemoteErrorabstract final class TransferableTypedData
dart:typed_data
abstract final class ByteBufferabstract final class TypedDatafinal class Endianabstract final class ByteDataabstract final class Int8Listabstract final class Uint8Listabstract final class Uint8ClampedListabstract final class Int16Listabstract final class Uint16Listabstract final class Int32Listabstract final class Uint32Listabstract final class Int64Listabstract final class Uint64Listabstract final class Float32Listabstract final class Float64Listabstract final class Float32x4Listabstract final class Int32x4Listabstract final class Float64x2Listabstract final class Float32x4abstract final class Int32x4abstract final class Float64x2abstract final class UnmodifiableByteBufferViewabstract final class UnmodifiableByteDataViewabstract final class UnmodifiableUint8ListViewabstract final class UnmodifiableInt8ListViewabstract final class UnmodifiableUint8ClampedListViewabstract final class UnmodifiableUint16ListViewabstract final class UnmodifiableInt16ListViewabstract final class UnmodifiableUint32ListViewabstract final class UnmodifiableInt32ListViewabstract final class UnmodifiableUint64ListViewabstract final class UnmodifiableInt64ListViewabstract final class UnmodifiableInt32x4ListViewabstract final class UnmodifiableFloat32x4ListViewabstract final class UnmodifiableFloat64x2ListViewabstract final class UnmodifiableFloat32ListViewabstract final class UnmodifiableFloat64ListView
It's possible, dart:mirrors might also be made entirely final, if time permits.
@lrhn I appreciate your perspective, but I must disagree with the assertion that It's not, technically, considered breaking.... Allow me to share my viewpoint:
As a library creator, supporting all major Dart version updates is crucial to prevent the library from becoming obsolete. What occurred to libraries that failed to transition from Dart 1 to 2.X?
The final class example is an excellent illustration. Introducing final class in Dart standard libraries disrupts all code dependent on those classes when transitioning to Dart 3, generating unplanned work for library authors.
When I examine the decision to make MapEntry a final class, it appears to be final for the sake of precaution rather than necessity.
Please don't misunderstand me; I adore Dart and the team behind it, and I will always be thankful for the impact it had on my life when I chose it for ClojureDart.
I would simply prefer minimal Breaking Changes.
Thanks for all your work 🙇