Suppressing deprecated warnings

Using Swift
, ,
1

Is there swift equivalent of:

#pragma GCC diagnostic ignored "-Wdeprecated-declarations"

1 Like
2

There is none in Swift.

3

Nothing at all? I wouldn't mind setting flags in Xcode's build phases panel.

4

It's not the Swift way. At least not yet.

See for instance

1 Like
5

That's interesting, thank you.

I can switch all warnings off via "-suppress-warnings" in "other swift flags", but can't do it on the individual file basis in "build phases" -> "compile sources" -> "compiler flags". (it's not the great UX that I can change it there but then nothing happens).

6

I can’t comment on the evolution side of this but, on the practical front…

  • If you’re specific concern is testing deprecated code, mark your test method as deprecated. The system will still run it but, because it’s deprecated, it won’t generate deprecation warnings.

  • In other situations I use the protocol workaround described here.

Needless to say, the second point does not make me happy (r. 31131633)-:

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

6 Likes
7

Thank you, the protocol hack removed lots of deprecation warnings from my code. I can't apply it for settable properties though:

private protocol HasName {
    var name: String? { get set }
}

struct Foo: Codable, HasName {
    @available(*, deprecated, renamed: "realName")
    var name: String?
    var realName: String? {
        get {
            // return name // Warning: 'name' is deprecated: renamed to 'realName'
            return (self as HasName).name // WORKS!
        }
        set {
            self.name = newValue // Warning: 'name' is deprecated: renamed to 'realName'
            (self as HasName).name = newValue
            // Error: Cannot assign to immutable expression of type 'String?'
        }
    }
}

or is there another hack?

For those of us who can't see it, is that about an ability to specify compiler flags per file?

8

is there another hack?

I’ve not looked into that in detail but my general strategy for dealing with such things is to introduce a deprecated function that wraps the facility I need. That ends up being a normal deprecated function, so I can use the protocol hack to call it from a non-deprecated context.

For those of us who can't see it, is that about an ability to specify
compiler flags per file?

It’s more like a general cry for help (-:

If this topic is near and dear to your heart, I encourage you to bring it up again on Swift Evolution (after reading up on previous attempts).

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple

9

the crux of the matter is that self as HasName is an r-value (it is immutable). The following looks ok-ish although it's a bit scary to force-case to a type back from protocol. Will give it a try.

private protocol HasName {
    var name: String? { get set }
}

struct Foo: Codable, HasName {
    @available(*, deprecated, renamed: "realName")
    var name: String?
    var realName: String? {
        get {
            return (self as HasName).name
        }
        set {
            var x = self as HasName
            x.name = newValue
            self = x as! Foo
        }
    }
}
10

I just found this thread because I have a specific warning I would like to get rid of:

'CC_MD5' was deprecated in iOS 13.0: This function is cryptographically broken and should not be used in security contexts. Clients should migrate to SHA256 (or stronger).

This shouldn't be a deprecation warning in the first place, because just because MD5 is now considered insecure, it doesn't change the fact that it's still needed in my environments. The fact that Swift won't let me turn of the deprecation warning is a bit upsetting to me, because I feel patronized over something I have no control over.

Probably not the best section to comment on this, but if someone has a pointer where to bring this up, because I feel that the Swift dev's stance on not allowing us to turn off this warning in individual places is a bad idea, at least in this case.

Update: There is a workaround for this MD5 case: Swift should allow for suppression of warnings, especially those that come from Objective-C - #49 by bzamayo
Basically, instead of the outdated MD5 function from CommonCrypto, use the Insecure.MD5.hash (data: …) function from CryptoKit.

2 Likes
12

for the six or so months that 5.7.x was the dominant toolchain, there was an even more annoying example:

async
let _iCannotNameThisUnderscore = someAsyncCancellableOperation()
//  ^~~~~~~~~~~~~~~~~~~~~~~~~~
//  always generates an unused variable warning