I would like if there was a phantom type for integers that has information if a number can be 0 or not. So division could force you to check for != 0 at compile time.
That can be made in your programs. I've thinking recently whether I should try to make a small package for this kind of things... I just don't know if it worth it, as one can just make their own custom types for this 😕
5:05 Isn't that why there are labeled parameters in the language to prevent this positional programming folly? In fact, at 12:40, it could be argued that labeled parameters & default values would also the builder pattern not too relevant had it not been for opaque types.
Yeah labels can definitely help you distinguish parameters when they're all the same type, for sure! Labels are more about readability than correctness, though, and the compiler can never save if you get the *labels* the wrong way round. I don't think you should reach for this approach with phantom types for *everything* but it is definitely useful to have a way to express "structurally identical, nominally distinct"
Congrats!!!
really nice explanation of phantom types and gleam typing
amazing language
Bravo!
The builder pattern application is really cool. I guess you could finagle it to be a convenient way to handle conditionally required fields as well 🤔
I would like if there was a phantom type for integers that has information if a number can be 0 or not. So division could force you to check for != 0 at compile time.
That can be made in your programs. I've thinking recently whether I should try to make a small package for this kind of things... I just don't know if it worth it, as one can just make their own custom types for this 😕
Brilliant
5:05 Isn't that why there are labeled parameters in the language to prevent this positional programming folly?
In fact, at 12:40, it could be argued that labeled parameters & default values would also the builder pattern not too relevant had it not been for opaque types.
Yeah labels can definitely help you distinguish parameters when they're all the same type, for sure! Labels are more about readability than correctness, though, and the compiler can never save if you get the *labels* the wrong way round. I don't think you should reach for this approach with phantom types for *everything* but it is definitely useful to have a way to express "structurally identical, nominally distinct"
Would phantoms types be considered similar to branded types?