Consider tightening arguments that are `dynamic`

[natebosch]

The dynamic url which may be either a String or Uri is not an idiomatic pattern in Dart 2. You lose static checking and are forced to read the doc comment to get help with usage that is normally provided in your IDE. The migration would be easy, shift the Uri.parse call to the call site instead of inside the library code.

The downside here is that there is potentially a lot of code to migrate since this is such a widely used package. That is mitigated somewhat by the fact that you'll get static checking for the migration in the vast majority of cases, only dynamic invocations would be runtime failures.

[jamiewest]

Maybe annotate the old method signature as obsolete and add a new one that only takes a Uri.

[natebosch]

Adding an alternative would be the typical upgrade route. In this case it would likely leave us with less desirable naming and wouldn't save much cost in the migration. The vast majority of this will be caught statically and the migration is trivial so it doesn't really need an long rollout.

[jakemac53]

Another alternative that came up today would be to add an extension on the Uri class which adds all of these methods, something like:

extension Http on Uri {
  Future<Response> get({Map<String, String> headers}) =>  get(this, headers: headers);
}

This allows for static safety through this api, without conflicting with the existing api.

To accomodate strings we could add a toUri extension on String:

extension Uri on String {
  Uri get toUri => Uri.parse(this);
}

So final usage is like var response = await 'https://www.google.com'.toUri.get() etc.