Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

CI errors are known

@kouvel I am just wondering - does F# have a special treatment for Lock too?

Also, should Monitor.TryEnter throw an error if Lock object is passed? so other CIL languages could realize they need a special treatment here

cc @vzarytovskii

lock in F# is just a function, which takes a lock object and a function. No special treatment.

lock in F# is just a function, which takes a lock object and a function. No special treatment.

From my understanding, the problem is - we now have this Lock type and it shouldn't be used (behind the scene) with Monitor type, otherwise if user defines a Lock lock object and then mixes its usage with lock keyword or f# function (doesn't matter) with explicit TryEnter/Scope APIs they might run into terrible hard-to-repro bugs

Yea that's a good point. I'm not sure if there's a way to disallow Lock-typed objects to be used statically with the lock function. At least that would be a deterrent but the Lock type could also be easily casted away. Not sure if there is a good solution to that, thoughts?

A run-time check adds a bit of measurable cost to locking, and if done in the lock function may also increase code size because it seems to be inlined. Or maybe there should be some guidance such as not to use Lock with lock in F#?