Needless warning?

[dabrahams]

Description

This comment, that would seem to be needless, appears in several places:

  /// - Warning: Do not rely on anything about the array that is the target of
  ///   this method during execution of the `body` closure; it might not
  ///   appear to have its correct value. Instead, use only the
  ///   `UnsafeMutableRawBufferPointer` argument to `body`.
  ///

The law of exclusivity ensures that you aren't accessing the thing.

Reproduction

Expected behavior

x

Environment

swift-driver version: 1.115 Apple Swift version 6.0 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)
Target: arm64-apple-macosx15.0

Additional information

No response

[stephentyrone]

@natecook1000 wrote that comment a decade ago, let's see what he thinks...

[natecook1000]

Agreed that exclusivity checks prevent this kind of improper usage now, so it doesn't need to be a warning. The content of the note might still be useful, since it looks like it's caught as a dynamic check.

@amartini51, what do you think of this? Example symbol with that warning: https://developer.apple.com/documentation/swift/array/withunsafemutablebufferpointer(_:)

[amartini51]

Downgrading it from a warning to a note seems reasonable, if the current language checks for this kind of error, but you could experience that check by your program terminating.

[stephentyrone]

Yeah, we should document that a static or dynamic exclusivity check will prevent you from doing this, and if it is detected dynamically, you will experience that as a fault at runtime, rather than "warning: don't do this"

[dabrahams]

I don't see how this ends up being a dynamic check unless the array happens to be a class property (in which case all LOE enforcement on properties is dynamic). IIRC It's a mutating method on the array. Am I missing something?

[dabrahams]

Documentation that a static exclusivity check prevents you from doing anything is just noise IMO. Seems to me there's no reason documenting it here is any more important than documenting it on Int.+=, and we're not going to do that.