3 ms·

Would you really write a function find_prime_factors() that takes an input of type "integer" and an output of type "prime", that you have previously defined? T

Would you really write a function find_prime_factors() that takes an input of type "integer" and an output of type "prime", that you have previously defined? Then if you want to sum or multiply such primes you have to cast them back to integers. Maybe it makes sense for you, but for me this is the textbook example of useless over-engineering. The same ugliness occurs when using unsigned types to store values that happen to be positive. Well, in that case it is even worse, because it is incomplete and asymmetric. What's so special about the lower bound of the possible set of values? If it's an index to an array of length N, you'll surely want an integer type whose values cannot exceed N. And this is a can of worms that I prefer not to open...

dkersten 6y ago
> Would you really write a function find_prime_factors() that takes an input of type "integer" and an output of type "prime", that you have previously defined? If the language allows me to and its an important semantic part of my program, then yes. The same way as I would create types for units that need conversion. Unless I'm writing low level performance sensitive code, yes, I want to encode as much of my semantics as I can, so that I can catch mistakes and mismatches at compile time, make sure units get properly converted and whatnot. > What's so special about the lower bound of the possible set of values? Nothing, I would encode a range if I can. But many things don't have a knowable upper-bound but do have a lower bound at zero: you can't have a negative size (for most definitions of size), usually when you have a count of things you don't have negatives, you know that a dynamically sized array can never have an element index less than 0, but you may not know the upper bound. Also, the language has limitations, so I have to work within them. I don't understand your objection for using what is available to make sure software is correct. Also, remember that many of the security bugs we've seen in recent years came about because of C not being great at enforcing constraints. Are you really suggesting not to even try? > And this is a can of worms that I prefer not to open... And yet many languages do and even C++20 is introducing ranges which kind of sort of fall into this space.
giomasce 6y ago
To me it could totally make sense. It depends on the context, but I can very well see contexts where such a choice could make sense. For example, in line of principle it would make sense, for an RSA implementation, to accept to construct a type PublicKey only computing the product of two Prime's, and not two arbitrary numbers. And the Prime type would only be constructible by procedures that provably (perhaps with high probability) generate an actual prime number. It would be a totally sensible form of defensive programming. You don't want to screw up your key generation algorithm, so it makes sense to have your compiler help you to not construct keys from anything. For the same reason, say, in an HTTP server I could store a request as a char* or std::string, but I would definitely create a class that ensures, upon construction, that the request is valid and legitimate. Code that processes the request would accept HTTPRequest, but not char*, so that unverified requests cannot even risk to cross the trust boundary.

dkersten 6y ago

> Would you really write a function find_prime_factors() that takes an input of type "integer" and an output of type "prime", that you have previously defined? If the language allows me to and its an important semantic part of my program, then yes. The same way as I would create types for units that need conversion. Unless I'm writing low level performance sensitive code, yes, I want to encode as much of my semantics as I can, so that I can catch mistakes and mismatches at compile time, make sure units get properly converted and whatnot. > What's so special about the lower bound of the possible set of values? Nothing, I would encode a range if I can. But many things don't have a knowable upper-bound but do have a lower bound at zero: you can't have a negative size (for most definitions of size), usually when you have a count of things you don't have negatives, you know that a dynamically sized array can never have an element index less than 0, but you may not know the upper bound. Also, the language has limitations, so I have to work within them. I don't understand your objection for using what is available to make sure software is correct. Also, remember that many of the security bugs we've seen in recent years came about because of C not being great at enforcing constraints. Are you really suggesting not to even try? > And this is a can of worms that I prefer not to open... And yet many languages do and even C++20 is introducing ranges which kind of sort of fall into this space.

giomasce 6y ago

To me it could totally make sense. It depends on the context, but I can very well see contexts where such a choice could make sense. For example, in line of principle it would make sense, for an RSA implementation, to accept to construct a type PublicKey only computing the product of two Prime's, and not two arbitrary numbers. And the Prime type would only be constructible by procedures that provably (perhaps with high probability) generate an actual prime number. It would be a totally sensible form of defensive programming. You don't want to screw up your key generation algorithm, so it makes sense to have your compiler help you to not construct keys from anything. For the same reason, say, in an HTTP server I could store a request as a char* or std::string, but I would definitely create a class that ensures, upon construction, that the request is valid and legitimate. Code that processes the request would accept HTTPRequest, but not char*, so that unverified requests cannot even risk to cross the trust boundary.