Need to update package:dart_internal to support SDK version 2.5

[grouma]

The current Dart SDK version is 2.5.0-dev.0.0.

Ran into this error:
Because angular_components >=0.13.0 depends on observable ^0.22.2 which depends on dart_internal ^0.1.1, angular_components >=0.13.0 requires dart_internal ^0.1.1.
So, because dart_internal >=0.1.1 requires SDK version >=2.0.0-dev.12.0 <2.4.0 and webdev_example_app depends on angular_components ^0.13.0, version solving failed.

cc @nshahan

[nshahan]

@athomas @whesse

What can we do to ensure this is part of the release process before new 2.x releases (stable or dev) of the SDK get published on public channels?

This causes pub version solving failures for anyone with a transitive dependency on pkg:dart_internal every time we publish a new version.

[munificent]

@aadilmaan, can we add this to the release checklist? We just need to make sure we publish a new version of dart_internal with an expanded SDK constraint each time we ship a new minor version of the SDK. I'm happy to be the owner of the task if you want.

[aadilmaan]

Checklist has been updated and you are tagged as owner =).

[nshahan]

Thanks for updating the checklist! I published dart_internal: 0.1.5 with an expanded SDK constraint.

[sortie]

Can we do better than simply adding another item to the release checklist? Complicating the release process with manual steps involving multiple people has a cos, increases the risk of making a mistake, and takes more time.

The documentation dart_internal suggests the package is temporary. What is the status on deprecating it?

If it doesn't seem that the package is going away anytime soon, we might want to do something to avoid breakage like this for subsequent stable releases:

• Change the upper SDK constraint to <3.0.0. Although that's good for discouraging use, it is pulled in by package observable, which is indirectly used by a lot (through angular_components), so that means a lot of stuff is falsely not compatible with new stable releases. Is there any compelling reason for not supporting the latest SDK?
• We could make our release script automatically publish an upgrade to the package? That would keep the release procedure simple.

What do you think?

[munificent]

The documentation dart_internal suggests the package is temporary. What is the status on deprecating it?

There isn't currently any other alternative, and I don't think we'll get one until after NNBD and extension methods. (There was a chance that the design of extension methods would have covered this case and allowed us to remove dart_internal, but we went with a simpler, more static approach.)

Is there any compelling reason for not supporting the latest SDK?

This package talks to a special "dart:" library. We'd like to be able to deprecate and remove that library as soon as we have a better solution. If we set the constraint to "<3.0.0", then it means the SDK must continue to support that library through every single 2.x version. Otherwise, users would be broken if they used dart_internal with a version of the SDK that had removed that library.

Keeping the constraint tight lets us remove the "dart:" library in a 2.x release without breaking users.

[matanlurey]

Looking internally, this is used basically twice, once in Streamy and once in Observable, right?:

CustomList toCustomList(List list) {
  return extractIterableTypeArguments(list, <T>() {
    return CustomList<T>(list);
  });
}

Basically, type information has been lost by upcasting, but they want to retain the original (runtime) type so they can treat CustomList<dynamic> as CustomList<FooEntity> where List<FooEntity> is expected?

How will this be expected to work if/when implicit downcasts are no longer a thing? I would consider starting a process where we find ways to move these two libraries (and their users) off this requirement.

[munificent]

Looking internally, this is used basically twice, once in Streamy and once in Observable

I believe so.

Basically, type information has been lost by upcasting

I think it's actually been lost by serialization. We are deserializing a list ex nihilo and then need to be able to pass it to code that expects it to have the correct reified type. We added dart_internal specifically because I don't think there is any other way to plumb the expected type through the static type system. It's simply not there statically.

How will this be expected to work if/when implicit downcasts are no longer a thing?

I don't think that will affect it. There's still explicit downcasts.

I would consider starting a process where we find ways to move these two libraries (and their users) off this requirement.

We did spend a lot of time trying to find other solutions before settling on this. (That's why so few libraries use this hack. All of the others, we found other solutions. These were the sticking points.)

I don't think the capability this exposes is very common, but I do think it's a useful one. Dart is a reified language where type arguments hang around at runtime, so it makes sense for the language to give you a mechanism to access them and reuse them.

The specific way we expose it here is gross, but I hope we can add a better feature directly in the language to do it. If we're lucky, pattern matching will cover this. @eernstg has some ideas around there, I think.