Skip to content
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

Make it easy to use type B in place of type A when there is an obvious/explicit conversion from B -> A #107

Open
kevmoo opened this issue Nov 27, 2018 · 1 comment
Labels
request Requests to resolve a particular developer problem

Comments

@kevmoo
Copy link
Member

kevmoo commented Nov 27, 2018

Every place in pkg:http with a url parameter types it as dynamic.

Future<Response> get(url, {Map<String, String> headers}) => ...

void doWork() async {
  await get('http://example.com');
  await get(Uri.parse('http://example.com'));
  await get(42); // statically fine, but causes a runtime error
}

This is to support a common use case: devs often want to pass either Uri
or String to such methods. In the end, all String values are "upgraded"
to Uri before use. To support the desired flexibility, the user risks
runtime errors if something other than String or Uri are provided.

Flutter avoids this issue, by being explicit about types everywhere.

// Flutter
void giveMeABorder(BorderRadiusGeometry value) {}

void doWork() {
  giveMeABorder(const BorderRadius.all(
    Radius.circular(18),
  ));

  // User would like to write this, but...
  giveMeABorder(18); // static error
}

The existing request(s) for union types – https://github.com/dart-lang/sdk/issues/4938 and #83 – could be an option here, but it would require updating all parameters and setters to specify the supported types.

It'd be nice to be able to define explicit conversions so one could easily pass String to properties/params requiring Uri, etc.

@TobiasHeidingsfeld
Copy link

This would be great to have!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Requests to resolve a particular developer problem
Projects
None yet
Development

No branches or pull requests

2 participants