[Idea] #suppress(warning-identifier)


(Russ Bishop) #1

There are cases where I’d like to suppress a Swift compiler warning. Is there opposition to that idea from the core team or is it just something that hasn’t been looked at yet? (Forgive me if such a thing already exists and I just missed it)

My initial idea pre-bikeshedding:

#suppress(warning-identifier)
//some code
#unsuppress(warning-identifier)

The most common one I encounter is the trailing-closure syntax warning which can only be fixed by redesigning the API itself. I’ve also had to silence incorrect cast warnings (that are actually correct and execute just fine) by casting to Any first which is somewhat gross.

Russ


(Shawn Erickson) #2

I would prefer something like...

    #warn(no-warning-identifier)
    ...
    #warn(warning-identifier)

..to keep the warning identifier behavior the same in code and on the
command line.

The ability to push and pop warning modifications (set of) could also make
sense.

···

On Tue, Mar 8, 2016 at 10:31 AM Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote:

There are cases where I’d like to suppress a Swift compiler warning. Is
there opposition to that idea from the core team or is it just something
that hasn’t been looked at yet? (Forgive me if such a thing already exists
and I just missed it)

My initial idea pre-bikeshedding:

#suppress(warning-identifier)
//some code
#unsuppress(warning-identifier)

The most common one I encounter is the trailing-closure syntax warning
which can only be fixed by redesigning the API itself. I’ve also had to
silence incorrect cast warnings (that are actually correct and execute just
fine) by casting to Any first which is somewhat gross.

Russ
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution