3 ms·
You can't always encode every semantic mismatch in the type system (or be checked by the compiler in general). Although with a sufficiently powerful type system
by MauranKilom 4y ago
You can't always encode every semantic mismatch in the type system (or be checked by the compiler in general). Although with a sufficiently powerful type system, at least the ones that are reflected in variable naming should be catchable.
For example, the convention of naming your 4x4 matrix transforms AfromB leads to the following kind of composition:
vecInD = DfromC * CfromB * BfromA * vecInA
Here, you can very clearly spot any mismatch (e.g. if someone put BfromC in the middle instead). With the right language, you could also have each matrix source and destination reference frames encoded in the type system if you so desired.
Where it gets harder to produce errors is higher-level patterns that transcend adjacent names:
if (atomicVariable.read()) { /* something that assumes atomicVariable is true */ }
This should invite suspicion - it is clearly concurrent code, so what prevents atomicVariable from changing right after entering the if?
- spockz 4y agoReading ad-hoc is fine if you just want to observe the value at some point in time. That is why there is room for both a “peek” function, maybe should be called “unsafeRead”, and a “withValue” method that takes a function with the actual value as argument and locks the atomic variable while executing the closure. This prevents the user from ever forgetting to write the lock.
- MauranKilom 4y ago> Reading ad-hoc is fine if you just want to observe the value at some point in time. There are such cases, indeed. Double-checked locking comes to mind. But if the code inside the if does assume the atomic to have a given value, it is almost surely wrong (absent of other synchronization mechanisms, such as in double-checked locking).
- tialaramex 4y agoI agree with the thrust of your argument but for your harder example this is exactly the sort of thing Rust does encode in the type system? If I read that I'd assume the block cares not that atomicVariable is true but only that it was, at least briefly, true.
- MauranKilom 4y agoWell, you kind of underline my point: Rust does not encode the difference between "is true" and "was, at least briefly, true" in the type system. You can reach for other types/abstractions (and whatever data you touch inside the if might also have the borrow checker up in arms), but that above code as written is suspect.
- josephcsible 4y ago> Rust does not encode the difference between "is true" and "was, at least briefly, true" in the type system. Couldn't it encode that by taking advantage of the fact that nobody else can change a variable while you have it mutably borrowed?
- marcosdumay 4y agoIsn't that exactly what people do. This thread seems surreal to me. Rust type system does encode exactly what the later comments are complaining that isn't encoded. And you sate what code cares about the variable keeping its value through a code block, between a pair of braces.
- MauranKilom 4y agoWhat I meant was *For atomics*, rust does not encode the difference between "is true" and "was, at least briefly, true" in the type system. Obviously, rust has many ways to track this kind of distinction in a compile-time manner (and yes, the borrow checker is one of them). That was not in question.
- marcosdumay 4y agoHum, ok. You don't consider the borrow checker to be part of the type system. Well, it's perfectly fine to disagree on name definitions, but that is some fuzzy and dizzy line. Lifetimes impose themselves together with the static types features all the time.