Lock is internal about swift-log HOT 4 CLOSED

It is internal on purpose; swift-log should not expose any more types than the core logging interface things.

The situation with logs and concurrency primitives in Swift currently is a bit weird, since no such types exist in Swifts stdlib, however in order to avoid many libraries linking to someone's other's lock types such types are always internal in these libraries -- so that when a Lock type lands in standard library we can remove it here without breaking anyone's code.

You can copy the locks file to your own project if you want to use this Lock or you can use some other Lock structure (NSLock, or your own); https://github.com/apple/swift-log/blob/master/Sources/Logging/Locks.swift

from swift-log.

I do realize it is a bit weird that the docs example assumes the existence of the Lock type though...
Not sure what to do about this, it should definitely not be an example without locking as then people would be under impression that no locking is needed...

Perhaps we can add a comment next to the LogHandlerWithGlobalLogLevelOverride's Lock that "bring your own"?

from swift-log.

WDYT, @tomerd @weissi should we do something here?
Perhaps the minimal

Perhaps we can add a comment next to the LogHandlerWithGlobalLogLevelOverride's Lock that "bring your own"?

change would be good enough to resolve this ticket?

from swift-log.

@ktoso maybe we just use NSLock from Foundation?

from swift-log.