this post was submitted on 14 May 2024
303 points (91.1% liked)
Programmer Humor
31812 readers
592 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Data typing is important. If two types do not have the same in-memory representation but you treat them like they do, you're inviting a lot of potential bugs and security vulnerabilities to save a few characters.
ETA: The WONTFIX is absolutely the correct response here. This would allow devs to shoot themselves in the foot for no real gain, eliminating the benefit of things like mypy. Type safety is your friend and will keep you from making simple mistakes.
Even if they do have the same in-memory representation, you may want to assert types as different just by name.
AccountID: u64
TransactionID: u64
have the same in-memory representation, but are not interchangeable.
That is a very solid point. If user-defined types are NOT explicitly defined as compatible (supposing language support), they should not be.
In your example, if it were, say a banking system, allowing both types to be considered equivalent is just asking for customer data leaks.
Python does allow this with NewType. Type checkers see two different types, but it is the same class at runtime.