Seems incompatible with (modern) attempts/approaches at addressing time-of-check to time-of-use (TOCTOU) bugs?
Say in any concurrent environment (doesn’t really matter whether the environment is parallel or not), you have a store which manages some kind of resource. Then a nice way would be to have a API of roughly the form val get : ?timeout:int -> store -> resource option, which both answers the query “is there a free instance of the resource?” and also changes the state (breaking the principle if I didn’t misunderstand it).
If we are to adhere to the principle strictly then I’m guessing the code would read closer to
if free store then
let x = get store in
...
but then you have the TOCTOU problem. Of course one can argue that surrounding the (critical) section with locks would mitigate the problem, but I think the general consensus has been we are not very good at writing or analysing code written that way.
EDIT: Bumped into SCOOP (software) - Wikipedia while browsing further, which addresses my concern I guess, but I haven’t given much thought into it.