5 ms·

Any doesn't mean "doesn't care". Any means "YOLO, do whatever you want, I'm one of those cool parents who'll let you smoke and drink beer."

eyelidlessness 4y ago
What is the distinction?
- TheCleric 4y ago
  The distinction is just because you "don't care" about the values right now, nothing stops the next developer (including future you) from needing the values. So now you've gone from not caring to "enabling someone to shoot themselves in the foot" if they don't read the types of the parameters carefully. That's the difference.
  - eyelidlessness 4y ago
    The case I was trying to convey doesn’t narrow the actual type for anything outside its own function body. Any footgun that exists after the function call already existed before it. It just implies “I’m only looking at your keys not your values”.
    - TheCleric 4y ago
      I gathered what you meant. My point is what stops the next developer working on your codebase from adding code in the body of your function that accesses the values of the object in an unsafe way?
      - eyelidlessness 4y ago
        A bit of trust. I’m not aware of a type system that protects my coworkers from my bad decisions, only those humans do that.
    - consilient 4y ago
      > It just implies “I’m only looking at your keys not your values”. That's what `unknown` is for. `any` behaves like `never` (in covariant positions), which is exactly the opposite.
      - eyelidlessness 4y ago
        I don’t think that’s how `any` behaves in any position, but I’d be happy to be corrected. Please show me how `any` is treated as `never`.
        consilient 4y ago
        Here's a close to minimal example: const anyToNeverHelper = <T,>(t: any): number & T => t const absurd: never = anyToNeverHelper<never>(0)
        eyelidlessness 4y ago
        This is a good example of how `never` is treated as `never`. Everything is assignable to the bottom type and intersecting with it will always be the bottom type, by definition. It’s also a good example of how the top type `any` casts to whatever you choose, because that’s also by design. Both types are vacant, the bottom type is infectious. That’s a good thing. And it works the same way with `unknown`, which it also should because once something is known to be part of the null set it should stay known as the null set.
        consilient 4y ago
        > Everything is assignable to the bottom type Other way around: everything is assignable to the top type (`unknown`), and the bottom type (`never`) is assignable to everything. > It’s also a good example of how the top type `any` casts to whatever you choose Which is precisely why `any` isn't the top type: if you allow `any`, then types no longer form a lattice, and there is no bottom or top. If you restrict yourself to a sound fragment, then `unknown` is the top type. Compare `(x: unknown) => boolean` (two inhabitants up to function extensionality) to `(x: any) => boolean` (infinitely many inhabitants). > And it works the same way with `unknown`, which it also should because once something is known to be part of the null set it should stay known as the null set. But `unknown` isn't the null set: it's the "set" (insofar as we're pretending that types are sets of values, which isn't quite true) of all terms.

eyelidlessness 4y ago

What is the distinction?

TheCleric 4y ago
The distinction is just because you "don't care" about the values right now, nothing stops the next developer (including future you) from needing the values. So now you've gone from not caring to "enabling someone to shoot themselves in the foot" if they don't read the types of the parameters carefully. That's the difference.
- eyelidlessness 4y ago
  The case I was trying to convey doesn’t narrow the actual type for anything outside its own function body. Any footgun that exists after the function call already existed before it. It just implies “I’m only looking at your keys not your values”.
  - TheCleric 4y ago
    I gathered what you meant. My point is what stops the next developer working on your codebase from adding code in the body of your function that accesses the values of the object in an unsafe way?
    - eyelidlessness 4y ago
      A bit of trust. I’m not aware of a type system that protects my coworkers from my bad decisions, only those humans do that.
  - consilient 4y ago
    > It just implies “I’m only looking at your keys not your values”. That's what `unknown` is for. `any` behaves like `never` (in covariant positions), which is exactly the opposite.
    - eyelidlessness 4y ago
      I don’t think that’s how `any` behaves in any position, but I’d be happy to be corrected. Please show me how `any` is treated as `never`.
      - consilient 4y ago
        Here's a close to minimal example: const anyToNeverHelper = <T,>(t: any): number & T => t const absurd: never = anyToNeverHelper<never>(0)
        eyelidlessness 4y ago
        This is a good example of how `never` is treated as `never`. Everything is assignable to the bottom type and intersecting with it will always be the bottom type, by definition. It’s also a good example of how the top type `any` casts to whatever you choose, because that’s also by design. Both types are vacant, the bottom type is infectious. That’s a good thing. And it works the same way with `unknown`, which it also should because once something is known to be part of the null set it should stay known as the null set.
        consilient 4y ago
        > Everything is assignable to the bottom type Other way around: everything is assignable to the top type (`unknown`), and the bottom type (`never`) is assignable to everything. > It’s also a good example of how the top type `any` casts to whatever you choose Which is precisely why `any` isn't the top type: if you allow `any`, then types no longer form a lattice, and there is no bottom or top. If you restrict yourself to a sound fragment, then `unknown` is the top type. Compare `(x: unknown) => boolean` (two inhabitants up to function extensionality) to `(x: any) => boolean` (infinitely many inhabitants). > And it works the same way with `unknown`, which it also should because once something is known to be part of the null set it should stay known as the null set. But `unknown` isn't the null set: it's the "set" (insofar as we're pretending that types are sets of values, which isn't quite true) of all terms.