8000 Make it easy to use type B in place of type A when there is an obvious/explicit conversion from B -> A · Issue #107 · dart-lang/language · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

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.

Sign up for GitHub

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

Jump to bottom
Open
kevmoo opened this issue Nov 27, 2018 · 1 comment
Open

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

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.
@kevmoo kevmoo added the request Requests to resolve a particular developer problem label Nov 27, 2018
kevmoo added a commit that referenced this issue Nov 27, 2018
@kevmoo
Proposal for #107 - implicit constructors (#105)
95336f1
This was referenced Nov 27, 2018
Open
Merged
@leafpetersen leafpetersen mentioned this issue Mar 9, 2019
Closed
@eernstg eernstg mentioned this issue Apr 10, 2019
Open
@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
Assignees
No one assigned
Labels
request Requests to resolve a particular developer problem
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kevmoo @TobiasHeidingsfeld
0