Skip to content

Permit Coercions in Type Ascriptions#79730

Closed
b-naber wants to merge 3 commits intorust-lang:masterfrom
b-naber:permit-coercion-type-ascription
Closed

Permit Coercions in Type Ascriptions#79730
b-naber wants to merge 3 commits intorust-lang:masterfrom
b-naber:permit-coercion-type-ascription

Conversation

@b-naber
Copy link
Contributor

@b-naber b-naber commented Dec 5, 2020

We want to permit coercions of type ascriptions inside coercion sites. To implement this we introduce a TypeAscriptionCtxt, which we pass inside an Expectation down to sub-expressions. Once we encounter a coercion site, we set TypeAscriptionCtxt::Coercion in the Expectation and propagate this down into check_expr_with_expectation. Whenever we encounter a type ascription and TypeAscriptionCtxt::Coercion is set, we coerce the type ascription.

Since not all sites, in which check_expr_coercable_to_type calls originate, are coercion sites (e.g. ExprKind::Assign or some methods in op.rs use check_expr_coercable_to_type), we currently also pass a TypeAscriptionCtxt to check_expr_coercable_to_type. Exposing TypeAscriptionCtxt throughout typeck::check is probably bad, I'm not sure what's the best way to hide the Ctxt, maybe we could call different variants of 'check_expr_coercable_to_type' based on whether the site at which these calls originate is an actual coercion site or not?

Closes #78248

r? @nikomatsakis

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-coercions Area: implicit and explicit `expr as Type` coercions F-type_ascription `#![feature(type_ascription)]` S-blocked Status: Blocked on something else such as an RFC or other implementation work.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

permit coercion in type ascription

8 participants