You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several design discussions in Carbon have talked about "what direction does type information flow" in the context of type inference. Broadly, these discussions have seemed to advocate away from bi-directional type information flow.
Also more specifically, they have moved us away from a Hindley–Milner type system design for expression types, etc.
We should capture the underlying idea that informs these discussions as best we can and write it into a principle document that can be referenced. A nice property of such a principle is it can be relatively brief and doesn't need to be precise or exacting, but can still help indicate the directionality of Carbon's design in this space.
The text was updated successfully, but these errors were encountered:
Several design discussions in Carbon have talked about "what direction does type information flow" in the context of type inference. Broadly, these discussions have seemed to advocate away from bi-directional type information flow.
More specifically, they have advocated away from "inwards" flow such as the context using the result of a call expression (as opposed to the arguments) influencing overload selection: https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p2875.md#overloaded-call-operator
Also more specifically, they have moved us away from a Hindley–Milner type system design for expression types, etc.
We should capture the underlying idea that informs these discussions as best we can and write it into a principle document that can be referenced. A nice property of such a principle is it can be relatively brief and doesn't need to be precise or exacting, but can still help indicate the directionality of Carbon's design in this space.
The text was updated successfully, but these errors were encountered: