5 ms·

I'm not sure how much value such a feature would have, but both of your points are already addressed by the original wish. A passed in callback would have to be

I'm not sure how much value such a feature would have, but both of your points are already addressed by the original wish. A passed in callback would have to be pure too and a getter function couldn't be called unless it's marked pure too. WebStorm already colors property access differently then the custom getter, why wouldn't Typescript be able to differentiate? Your last argument is confusing: the same applies to everything in typescript. You can also pass in a string to a field that's demanding a number by using "as" so you never have any type guarantees in TS, there is value in it nonetheless. And the same would surely apply to pure functions (I.e. inpureFunction as PureFunction)()...) It could still be a valuable feature anyway

kevingadd 4y ago
All properties are potentially getters and any value can be a proxy.
- delaaxe 4y ago
  The point is about only being able properties marked as pure with special syntax, whatever their implementation
  - kevingadd 4y ago
    If a compiler makes safety guarantees that aren't actually guarantees, like "this function is pure because you made some naive promises you can't keep", it undermines your ability to rely on any of the verification it does. It's especially bad to do this if you're going to perform optimizations based on those safety guarantees (thankfully, typescript doesn't do that.) You can say 'don't use the pure keyword then' but the fundamental design of JS means that in practice almost no functions can be pure. The runtime has to identify cases on the fly where pure optimizations are actually valid.
    - Waterluvian 4y ago
      Isn’t that the model of TypeScript though? If your code ever brings in data from an outside source, somewhere in it you’re saying, “trust me, it’s typed as X.” Though now I’m doubting myself because maybe it’s possible to use complex enough assertion functions to really prove that. But even if you don’t, it’s still an incredibly useful language. You’re basically saying, if X is true then the rest of this program should fit together like so.”
      - kevingadd 4y ago
        Right, the thing is that a lot of typescript's assertions are valid even without complete top to bottom knowledge of the code being executed. Object shapes, for example, are pretty clean to reason about (proxies do complicate this some, but not nearly as bad as they do purity), which means structural typing stuff can just work. It doesn't matter whether property 'x' is a getter or a value as if all you need to know is whether an object has a property named x, and if you need to know the type that also is something you can check without needing to know whether reading the value has side effects. And shapes/types can be verified at runtime as long as state isn't mutated between verification and use. You're right that in the end once you pull in outside data you're having to make promises that you may not be able to keep - I just think purity is an especially difficult set of promises to keep, and the existence of proxies and getters in JS (along with how they work) makes purity basically impossible, so it's just a footgun waiting to be used. And TS isn't going to optimize your code using it, so it's not really delivering value either.
        delaaxe 4y ago
        Proxies and state-mutating getter functions are pretty edge features of JS tbh
CGamesPlay 4y ago
Any property access could be a getter function, and TypeScript doesn't know which properties are getters and which aren't [0]. Similarly for Proxies, anything could be a proxy and the design goal of Proxies is that they cannot be differentiated from regular values. But imagine that TypeScript, in addition to pure functions, also allows you to tag objects as "POD objects" or "JavaScript objects". The POD ("plain old data") objects can't be proxies or have impure getter methods, and the "pure" keyword actually means "pure if all arguments are POD objects" (this is to avoid having to write N purity overloads for an N-ary function). You want to call a pure method from your impure method, and pass it one of your arguments. Your arguments now need to be declared to be POD objects, which means they are incompatible with the rest of your code base. This has to go all the way up... it's basically "colored functions" except it's colored objects this time, and the colors are completely incompatible (async functions can call sync functions, but impure functions can't call pure functions with impure arguments, and pure functions can't call impure functions at all). [0] https://www.typescriptlang.org/play?#code/C4TwDgpgBAkgYgewVAvFA3gWAFBSgIwEMAnALigGdhiBLAOwHMBuHAXxxwGME6qoAzJAEFy8JKgwES5AEREAXjKisW2br2ACkAIVGJkadFAYRNRYgAoAlJOKmArsTpQA7vQAmCFwDoANgk5CYBoebwALO34mZWUmIA https://www.typescriptlang.org/play?#code/C4TwDgpgBAkgYgewVA...
- 411111111111111 4y ago
  > Any property access could be a getter function, and TypeScript doesn't know which properties are getters and which aren't I'm aware. That doesn't make it impossible to differentiate as Webstorm shows by coloring the bar differently for fooA vs fooB in your example. But yes, it would have to be implemented as part of that pure feature.

kevingadd 4y ago

All properties are potentially getters and any value can be a proxy.

delaaxe 4y ago
The point is about only being able properties marked as pure with special syntax, whatever their implementation
- kevingadd 4y ago
  If a compiler makes safety guarantees that aren't actually guarantees, like "this function is pure because you made some naive promises you can't keep", it undermines your ability to rely on any of the verification it does. It's especially bad to do this if you're going to perform optimizations based on those safety guarantees (thankfully, typescript doesn't do that.) You can say 'don't use the pure keyword then' but the fundamental design of JS means that in practice almost no functions can be pure. The runtime has to identify cases on the fly where pure optimizations are actually valid.
  - Waterluvian 4y ago
    Isn’t that the model of TypeScript though? If your code ever brings in data from an outside source, somewhere in it you’re saying, “trust me, it’s typed as X.” Though now I’m doubting myself because maybe it’s possible to use complex enough assertion functions to really prove that. But even if you don’t, it’s still an incredibly useful language. You’re basically saying, if X is true then the rest of this program should fit together like so.”
    - kevingadd 4y ago
      Right, the thing is that a lot of typescript's assertions are valid even without complete top to bottom knowledge of the code being executed. Object shapes, for example, are pretty clean to reason about (proxies do complicate this some, but not nearly as bad as they do purity), which means structural typing stuff can just work. It doesn't matter whether property 'x' is a getter or a value as if all you need to know is whether an object has a property named x, and if you need to know the type that also is something you can check without needing to know whether reading the value has side effects. And shapes/types can be verified at runtime as long as state isn't mutated between verification and use. You're right that in the end once you pull in outside data you're having to make promises that you may not be able to keep - I just think purity is an especially difficult set of promises to keep, and the existence of proxies and getters in JS (along with how they work) makes purity basically impossible, so it's just a footgun waiting to be used. And TS isn't going to optimize your code using it, so it's not really delivering value either.
      - delaaxe 4y ago
        Proxies and state-mutating getter functions are pretty edge features of JS tbh

CGamesPlay 4y ago

Any property access could be a getter function, and TypeScript doesn't know which properties are getters and which aren't [0]. Similarly for Proxies, anything could be a proxy and the design goal of Proxies is that they cannot be differentiated from regular values. But imagine that TypeScript, in addition to pure functions, also allows you to tag objects as "POD objects" or "JavaScript objects". The POD ("plain old data") objects can't be proxies or have impure getter methods, and the "pure" keyword actually means "pure if all arguments are POD objects" (this is to avoid having to write N purity overloads for an N-ary function). You want to call a pure method from your impure method, and pass it one of your arguments. Your arguments now need to be declared to be POD objects, which means they are incompatible with the rest of your code base. This has to go all the way up... it's basically "colored functions" except it's colored objects this time, and the colors are completely incompatible (async functions can call sync functions, but impure functions can't call pure functions with impure arguments, and pure functions can't call impure functions at all). [0] https://www.typescriptlang.org/play?#code/C4TwDgpgBAkgYgewVAvFA3gWAFBSgIwEMAnALigGdhiBLAOwHMBuHAXxxwGME6qoAzJAEFy8JKgwES5AEREAXjKisW2br2ACkAIVGJkadFAYRNRYgAoAlJOKmArsTpQA7vQAmCFwDoANgk5CYBoebwALO34mZWUmIA https://www.typescriptlang.org/play?#code/C4TwDgpgBAkgYgewVA...

411111111111111 4y ago
> Any property access could be a getter function, and TypeScript doesn't know which properties are getters and which aren't I'm aware. That doesn't make it impossible to differentiate as Webstorm shows by coloring the bar differently for fooA vs fooB in your example. But yes, it would have to be implemented as part of that pure feature.