3 ms·

I’ve always grokked primitive types as mapping to different concepts used when storing values in memory. A string is some bytes in a line with a terminator at

I’ve always grokked primitive types as mapping to different concepts used when storing values in memory. A string is some bytes in a line with a terminator at the end. An integer is a group of signed or unsigned bytes. An enum value points at another value with a pointer. Etc. What I think this describes is some validation classes, which don’t need to be built into a language’s runtime. Primitive types have a real reason for existing when compiling these apps, a validation class doesn’t. It can just be a library, in which case this is a nice API for validation!

tsimionescu 4y ago
This doesn't make too much sense. For example, (on 64-bit Linux) long, unsigned long, long long, unsigned long long, double, void*, char*, int(*)(int), []int are all stored in exactly the same way: they are a 64-bit value somewhere in memory. You could argue that double is different since it's just packing a mantissa and exponent, and that signed is actually a sign bit + a 63-byte number, but that still leaves long*, int(*)(int) and long being the same thing: a 64-byte number. Not to mention that struct X { long X } has the same representation as well most likely. Instead, it's more normal to think of types (primitive or not) as descriptions of what can be done with a particular kind of value - from this point of view, it's obvious why long* is a different type than long (you can dereference it) or int(*)(int) (you can't call it). With this new definition, we can also see why we may want to distinguish EmailAddress from String - you can send an email to an EmailAddress, but you can't send an email to a String; conversely, you can sort the characters of a String, but you can't sort the characters of an EmailAddress.