4 ms·
The problem with this viewpoint is that the baseline is pretty arbitrary. Using a newtype carries a conceptual cost of wrapping and unwrapping... but using u8 d
by tikhonj 5y ago
The problem with this viewpoint is that the baseline is pretty arbitrary. Using a newtype carries a conceptual cost of wrapping and unwrapping... but using u8 directly carries the conceptual cost of remembering what any given u8 means! What makes that the baseline and newtype wrapping a cost over that as opposed to using domain concepts in types as the baseline and using native types the cost?
- yyyk 5y agoWell, imagine that your code is serializing and deserializing someone else's type. You probably care more in that context about the underlying type and not the newtype, and the newtype doesn't help you. Now, I did say this option was worth it. And there are cases of being too conservative (Golang?). But when designing and programming, one should look at the tradeoff. Abstraction is not always worth its costs [EDIT: and sometimes you can have less costs by a better abstraction, but being aware of the costs helps to think about the better abstraction].
- dnautics 5y agothat's exactly what should keep you awake at night. Because the conceptual cost is arbitrary and not meaningfully measurable in a quantitative sense, people tend to elide over it, but though it's not measurable that cost is no less real and might bubble up in the form of someone losing money, or in some cases, causing physical harm.