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
In current TypeScript the following is permitted. Which makes point-free programming style a very risky business.
interfaceA{x: nuber;}interfaceB{x: number,y: string}functioncopyB(value: B) : B{return{x: value.x,y: value.y};}letvalues : A[]=[];letcopied=values.map(copyB);// <-- a problem due to using bi-variance for checking assignment compatibility
Workaround
One can use function literals instead of references, but this brings unnecessary overhead with an extra function wrap.
let copied = values.map(value => copyB(value)); // <-- gives a compile error as expected
Solution idea
During compiling (internally), why won't we transform arguments that are FUNCTON REFERENCES (problematic) into arguments that are FUNCTION LITERALS (that work as expected)?
It looks like that such transformation can be done 100% mechanically:
pull the signature of a function specified as a reference
replace the function reference with the function literal by:
matching each parameter of the pulled signature with a parameter of the new function literal
using the result of the function reference invokation as the return value of the function literal
// before transformation:
...map(copyB); // <-- function reference
// after transformation:
...map(value => copyB(value)) // <-- function literal
The text was updated successfully, but these errors were encountered:
zpdDG4gta8XKpMCd
changed the title
bi-variant assignment compatibility for function parameters
disallow bi-variant assignment compatibility for function parameters
Dec 6, 2015
zpdDG4gta8XKpMCd
changed the title
disallow bi-variant assignment compatibility for function parameters
disallow bi-variant assignment compatibility for function reference parameters
Dec 6, 2015
Problem
In current TypeScript the following is permitted. Which makes point-free programming style a very risky business.
Workaround
One can use function literals instead of references, but this brings unnecessary overhead with an extra function wrap.
Solution idea
During compiling (internally), why won't we transform arguments that are FUNCTON REFERENCES (problematic) into arguments that are FUNCTION LITERALS (that work as expected)?
It looks like that such transformation can be done 100% mechanically:
The text was updated successfully, but these errors were encountered: