4 ms·

It's been deprecated since 2012, so it probably shouldn't be called from APIs introduced 3 years ago anyway.

• isodev 2y ago
  I think probably Xcode should say something if one tries to. (concurrency checking is brand new in Swift 6). Like the post says, it’s not always clear if you’re working with a class which inherits from NSCopyObject, so how does one “break out” of strict concurrency to copy an object like this?
  • galad87 2y ago
    The articles says it's used mostly in old UI components like NSCell, that can only be used on the main thread. NSImage & NSImageRep have questionable thread safety, and I don't know how often NSAnimation is copied on a non main thread.
    • isodev 2y ago
      And is SwiftUI's @MainActor annotation "main thread" enough for this? e.g. if a View with @MainActor annotation renders a child which is a NSCell/NSImage/NSImageRep/NSAnimation wrapped in a representable - all is good? I don't know why Apple keeps adding things to Swift without removing the old things.
      • klausa 2y ago
        For two main reasons: a) because there are untold amount of apps relying on the old things b) because the people working on the language are not the same people working on the frameworks.
        • isodev 2y ago
          So we just have to live with every mistake and “mood” Apple has dropped into Swift, accumulating complexities and “time to ponder what I’m doing wrong” while debugging?
          • favorited 2y ago
            NSCopyObject isn't something that was "dropped into Swift," it's a function that has existed since the mid 90s, and is available in Swift because Swift can call C and Objective-C functions. But yes, you do have to live with the history of the platform you're developing for. Opportunities to break backwards-compatibility are few and far-between, because users don't like when OS updates make their apps stop working.