{"id":46501,"date":"2025-01-22T13:52:10","date_gmt":"2025-01-22T18:52:10","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=46501"},"modified":"2025-01-22T13:52:10","modified_gmt":"2025-01-22T18:52:10","slug":"swift-proposal-opt-in-strict-memory-safety-checking","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/01\/22\/swift-proposal-opt-in-strict-memory-safety-checking\/","title":{"rendered":"Swift Proposal: Opt-in Strict Memory Safety Checking"},"content":{"rendered":"

SE-0458<\/a>:<\/p>\n

For example, Swift solves null references with optional types. Statically, Swift prevents you from using an optional reference without checking it first. If you’re sure it’s non-null, you can use the !<\/code> operator, which is safe because Swift will dynamically check for nil<\/code>. If you really can’t afford that dynamic check, you can use unsafelyUnwrapped<\/code><\/a>. This can still be correct if you can prove that the reference is definitely non-null for some reason that Swift doesn’t know. But it is an unsafe feature because it admits violations if you’re wrong.<\/p>

[…]<\/p>

A compiler flag -strict-memory-safety<\/code> that enables warnings for all uses of unsafe constructs within a given module. All warnings will be in the diagnostic group Unsafe<\/code>, enabling precise control over memory-safety-related warnings per SE-0443<\/a>. When strict memory safety is enabled, the StrictMemorySafety<\/code> feature will be set: #if hasFeature(StrictMemorySafety)<\/code> can be used to detect when Swift code is being compiled in this mode.<\/p>

[…]<\/p>

Because UnsafeBufferPointer<\/code> and UnsafePointer<\/code> are @unsafe<\/code> types, this code will get a warning regardless of whether the declarations were marked @unsafe<\/code>, because having unsafe types in the signature of a declaration implies that they are @unsafe<\/code>. This helps us identify more unsafe code even when the libraries we depend on haven’t enabled strict safety checking themselves.<\/p>

To suppress these warnings, the expressions involving unsafe code must be marked with unsafe<\/code> in the same manner as one would mark a throwing expression with try<\/code> or an asynchronous expression with async<\/code>.<\/p><\/blockquote>\n\n

Previously:<\/p>\n