3 ms·
Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + opera
by Certhas 2y ago
Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive.
Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work.
- s1mplicissimus 2y ago> Yes, but generic code complicates the picture. The things I saw were like: The documentation says you need a number but actually all you need is for the + operator to be defined. So if your interface only accepts numbers it is unnecessarily restrictive. if you really need a number, why not use a type specifically aligned to that (something like f32|f64|i32|i64 etc...) instead of relying on + operator definition? > Conversely some codepath might use * but that is not in the interface, so your generic code works for numbers but fails for other types that should work. do we agree that if it's not in the interface you are not supposed to use it? conversely if you want to use it, the interface has to be extended?
- Certhas 2y agoYes, the second case is a bug in the interface. For the first case you have it the wrong way around. My generic code would work on things that are not numbers but I prevent you from calling it because I didn't anticipate that there would be things you can add that are not numbers. (Better example: require an array when you really only need an iterable).