4 ms·

I'm questioning this advantage: > Improved type safety: Currying can help improve type safety by ensuring that each curried function takes exactly one argument

I'm questioning this advantage: > Improved type safety: Currying can help improve type safety by ensuring that each curried function takes exactly one argument of the correct type. This can help catch errors at compile time and make your code more robust. Why would non-curried functions have worse type safety?

nanodeath 3y ago
I _think_ what they're saying is a specialized/curried function that takes a single argument is better than the method it's replacing that takes three strings or whatever. That is, `foo.a("a").b("b").c("c")` is better than `foo.a("a", "b", "c")`. Which...sure, but 1. if you're really passing 2-3 parameters in with identical types, maybe use inline value classes instead? Or at least type aliases?, and 2. if you can't or don't want to do that, named arguments help.
- mattsan 3y ago
  Type safe builders/factories work and should be used where appropriate (e.g. to catch invalid state at compile time) but I don't see how this has anything to do with the currying shown in the post. The compiler checks the param types whether the function has a single param or not.
__jem 3y ago
Passing around functions that have already been partially applied means that downstream users can't incorrectly call or accidentally modify the arguments which have already been applied. Whether this actually results in more safety is unclear, as there are other language features or API design that accomplishes the same thing.
- mattsan 3y ago
  Yeah I would think that downstream users would just expect a function that only takes in the params that they specify - leave it up to the API user to just make a closure on the spot.
mumblemumble 3y ago
If we're using the more formal/traditional definition of "type safe" of "won't crash or go into an undefined state due to runtime type errors", then I think that it doesn't actually change the type safety situation at all. Assuming we're actually using the more common colloquial meaning of "helps prevent logical errors due to a failure of the program's types to properly convey semantic distinctions" rather than the more I actually think it's kind of the opposite. When you curry a function that takes multiple arguments of the same type but treats them differently (so, not something like +), it gets easier to lose track of which is which in code that makes heavy use of partial application. Without partial application, someone reading the code is more likely to see that it's being called with two arguments of the same type and think to double-check the documentation if they're unsure which is which.

nanodeath 3y ago

I _think_ what they're saying is a specialized/curried function that takes a single argument is better than the method it's replacing that takes three strings or whatever. That is, `foo.a("a").b("b").c("c")` is better than `foo.a("a", "b", "c")`. Which...sure, but 1. if you're really passing 2-3 parameters in with identical types, maybe use inline value classes instead? Or at least type aliases?, and 2. if you can't or don't want to do that, named arguments help.

mattsan 3y ago
Type safe builders/factories work and should be used where appropriate (e.g. to catch invalid state at compile time) but I don't see how this has anything to do with the currying shown in the post. The compiler checks the param types whether the function has a single param or not.

__jem 3y ago

Passing around functions that have already been partially applied means that downstream users can't incorrectly call or accidentally modify the arguments which have already been applied. Whether this actually results in more safety is unclear, as there are other language features or API design that accomplishes the same thing.

mattsan 3y ago
Yeah I would think that downstream users would just expect a function that only takes in the params that they specify - leave it up to the API user to just make a closure on the spot.

mumblemumble 3y ago

If we're using the more formal/traditional definition of "type safe" of "won't crash or go into an undefined state due to runtime type errors", then I think that it doesn't actually change the type safety situation at all. Assuming we're actually using the more common colloquial meaning of "helps prevent logical errors due to a failure of the program's types to properly convey semantic distinctions" rather than the more I actually think it's kind of the opposite. When you curry a function that takes multiple arguments of the same type but treats them differently (so, not something like +), it gets easier to lose track of which is which in code that makes heavy use of partial application. Without partial application, someone reading the code is more likely to see that it's being called with two arguments of the same type and think to double-check the documentation if they're unsure which is which.