You can do that in Swift (and, I suspect, lots of languages).
Swift has a fairly decent assertion/precondition facility, as well as reflection[0]. They also have a decent test framework[1] (and I know that some folks have extended it, to do some cool stuff).
Some of these add significant overhead, so they aren't practical for shipping runtime, but they can be quite useful for debug-mode validation.
Assertions are a very old technique. I think I first encountered them in Writing Solid Code, in the 1990s. Back then, we had to sort of "roll our own," but they have since, become integrated into languages.
Of course, all the tools in the world, are worthless, if we don't use them.
> Of course, all the tools in the world, are worthless, if we don't use them.
True...
I wonder if there would be any way, to simplify the syntax, and require basic assertions to be on every function. There might be a super easy cop-out like `any`, but at least by being forced to type it, you become aware of what it means and that it exists.
Almost like:
`public any int addXandY (any int x, any int y) {`
I also wonder, if there could be such a thing as an `assertion exception` (or whatever it would be called). Maybe it would just make things a mess, but I'm just thinking out loud. Basically, you could have a function that behaves a specific way 90% of the time, but for that 10% of the time where it doesn't work, you could pass that assertion exception to override. Maybe that would just be awful... or it would keep functions much cleaner?
Maybe you wouldn't even call it an exception. You'd just have multiple sets of assertions that could be applied to each function call.
I just had another thought. What if you could have a bank of assertions? Like this pseudocode:
```
assertion acceptableBlastNumber (int x) {
x < 25;
x > 5;
}
assertion acceptableBlastRadius (int x) {
x > 500;
x < 1000;
! (x > 750 && x < 800)
}
assertion acceptableBlastAddedNumber (int x) {
x < 1025;
x > 505;
}
public acceptableBlastAddedNumber int addBlastNumbers (acceptableBlastNumber int x, acceptableBlastRadius int y) {
return x + y;
}
addBlastNumbers (10, 720) => 730
addBlastNumbers (26, 750) => Exception
```
Though I suppose that this is getting really close to just... classes. It would just be a little more... inline? Less complicated because it would never hold state? Though I suppose, this would also mean your class can just focus on being an objec, and not on having all the definitions for the things inside it, because you can have an <assertion> <object> rather than just <object>.
Swift has a fairly decent assertion/precondition facility, as well as reflection[0]. They also have a decent test framework[1] (and I know that some folks have extended it, to do some cool stuff).
Some of these add significant overhead, so they aren't practical for shipping runtime, but they can be quite useful for debug-mode validation.
Assertions are a very old technique. I think I first encountered them in Writing Solid Code, in the 1990s. Back then, we had to sort of "roll our own," but they have since, become integrated into languages.
Of course, all the tools in the world, are worthless, if we don't use them.
[0] https://developer.apple.com/documentation/swift/debugging-an...
[1] https://developer.apple.com/documentation/xctest/