Any plans of replacing `dynamic` with `Object?`, `List<int>` with `Uint8List`

[gintominto5329]

Hello,

Reading Future func() seems very bad, compared to Future<Object> func(), especially in the code, of a core library (indexed_db for example), and may depreciate the intent of code quality, towards the language team, among the readers of the code,

Also the RandomAccessFile class has methods, void writeFromSync(List<int> buffer,, int readIntoSync(List<int> buffer,, which operate on List<int> instead of Uint8List, although the former is converted into the latter, internally, so are there any plans to replace int list parameters, with byte arrays,
Maybe in dart 3,

If not, can there we some member function, like Uint8List readSync(int count), which takes a byte array, for writing to a file, maybe like void writeSync(Uint8List bytes),

Thanking you,

[julemand101]

Not sure I understand the request about Uint8List. You are aware that Uint8List implements the type List<int> so any method that takes List<int> can also take an Uint8List object? It also means that if a method returns Uint8List, we can use the returned value as if it was a List<int> object.

[Wdestroier]

Future func() is better than Future<Object> func(), because with the latter the cast is (almost) always explicit. Example:

Future funcA() => ...;
void funcB(String s) => ...;
funcB(await funcA());

Future<Object> funcX() => ...;
void funcY(String s) => ...;
funcY(await funcX() as String)

[mateusfccp]

@Wdestroier Au contraire.

Future<Object> func() is better than Future func(), because with the former the cast has (almost) always to be explicit.

I would, however, encourage promoting instead.

final x = await funcX();
if (x is String) {
  funcY(x);
}

This way, we are 100% sure that we won't get an edgy-case runtime error because, for some weird reason, funcX does not return String.

[lrhn]

Specific changes to individual libraries is always possible. There is no general plan to go over all the libraries and change things.

Changing a Future (aka Future<dynamic>) to Future<Object?> is a breaking change.
I'd be positive to writing Future<dynamic> explicitly, instead of just Future, but changing the type to not be dynamic is non-trivial, since it will break any code currently relying on the type being dynamic.

Changing an argument type from List<int> to Uint8List is also breaking change, so it's unlikely to just happen.
(I'm sure the authors would have loved it to be Uint8List from the start, but it wasn't.)

Labeling this as an enhancement request for RandomAccessFile, since that's the most concrete request.

[mraleph]

To provide some context: this is related to #36900 - @tvolkert has previously done a pass over various APIs and strengthened their return types from List<int> to Uint8List. We have not done similar strengthening for parameters.

[gintominto5329]

Actually I asked this, because of Dart 3, that its a major version, so the system could be open, for breaking changes

[lrhn]

We can make breaking changes, but it's always a cost/benefit trade-off.
These changes are fairly low benefit, so the cost of breaking existing code weighs heavily against it.

If we did the same change as part of a larger "no-implicit-dynamic" clean-up, it would be part of a larger benefit, and part of a larger required migration, so it would be a smaller incremental cost.
(I hope we'll get to do such a change at some point. Fixing individual declarations before that is less likely to happen, unless it's a recognized pain point.)

[aam]

Closing per @lrhn comment above regarding cost/benefit trade-off.