проблема

Недавно я обнаружил предупреждение в сторонней утилите (WEPopover) в этом фрагменте кода:

_effectivePopoverContentSize = _contentViewController.contentSizeForViewInPopover;

Это генерировало следующее предупреждение:

warning: 'contentSizeForViewInPopover' is deprecated: first deprecated in iOS 7.0 - Use UIViewController.preferredContentSize instead. [-Wdeprecated-declarations]
            _effectivePopoverContentSize = _contentViewController.contentSizeForViewInPopover;

Одним из временных исправлений для этого в Objective-C является использование диагностики прагма-кланга, чтобы заглушить ошибку (я позволю автору кода разобраться с настоящим исправлением). Поэтому я пересмотрел код так:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
            _effectivePopoverContentSize = _contentViewController.contentSizeForViewInPopover;

#pragma clang diagnostic pop

Вопрос

Это прекрасно работает, но это заставило меня задуматься о том, что если существует какая-либо альтернатива, где нужно было бы отключить подобное ложное срабатывание предупреждения при кодировании в Swift?

Соображения

Я наблюдал тот факт, что я могу деактивировать такие предупреждения в рамках всего проекта (используя настройки XCode), но я хочу рассмотреть встроенную проблему, как отмечено выше. Я также рассмотрел добавление #define в файл .bridging-header.h в моем проекте Swift и каким-то образом использовал это; Однако я ищу Swift конкретное решение этой проблемы. Я понимаю, что прагма больше не доступна, и я искал SO и нашел похожие, но не повторяющиеся вопросы.

ОБНОВЛЕННОЕ РЕШЕНИЕ: Swift 2.0

Приведенный ответ отвечает на мои опасения по поводу встроенных предупреждений. Команда доступности должна позволять вообще избегать таких проблем, потому что один будет предупрежден во время компиляции.

Книга Apple Swift окончательно утверждает:

«Вы используете условие доступности в операторе if или guard для условного выполнения блока кода в зависимости от того, доступны ли API, которые вы хотите использовать, во время выполнения. Компилятор использует информацию из условия доступности, когда он проверяет, что API в этом «блоке кода» доступны.

 if #available(iOS 9, OSX 10.10, *) {
 // Use iOS 9 APIs on iOS, and use OS X v10.10 APIs on OS X 
 } else {
 // Fall back to earlier iOS and OS X APIs 
 }

”

Отрывок из: Apple Inc. «Язык программирования Swift (предварительный выпуск Swift 2)». IBooks.https://itun.es/us/k5SW7.l ”

Можно даже использовать защитное заявление в сочетании с доступностью, чтобы выйти из области досрочно, если не будут выполнены доступные условия.

guard #available(iOS 8.0, OSX 10.10, *) else { return }

Выдержка из: Apple Inc. «Использование Swift с какао и Objective-C (предварительный выпуск Swift 2)». IBooks.https://itun.es/us/utTW7.l

Кроме того, мои проблемы, связанные с обработкой макросов, рассмотрены ниже. Принимая во внимание, что у Swift нет препроцессора, эти инструменты кажутся подходящими.

“Простые Макросы

Где вы обычно использовали директиву #define для определения примитивной константы в C и Objective-C, в Swift вы вместо этого используете глобальную константу. Например, определение константы #define FADE_ANIMATION_DURATION 0.35 может быть лучше выражено в Swift с помощью let FADE_ANIMATION_DURATION = 0.35. Поскольку простые константообразные макросы отображаются непосредственно в глобальные переменные Swift, компилятор автоматически импортирует простые макросы, определенные в исходных файлах C и Objective-C ».

Выдержка из: Apple Inc. «Использование Swift с какао и Objective-C (предварительный выпуск Swift 2)». IBooks.https://itun.es/us/utTW7.l

“Сложные макросы

Сложные макросы используются в C и Objective-C, но не имеют аналогов в Swift. Сложные макросы - это макросы, которые не определяют константы, включая заключенные в скобки функциональные макросы. Вы используете сложные макросы в C и Objective-C, чтобы избежать ограничений проверки типов или избежать повторного ввода большого количества стандартного кода. Однако макросы могут затруднить отладку и рефакторинг. В Swift вы можете использовать функции и шаблоны для достижения тех же результатов без каких-либо компромиссов. Следовательно, «сложные макросы в исходных файлах C и Objective-C недоступны для вашего кода Swift».

Выдержка из: Apple Inc. «Использование Swift с какао и Objective-C (предварительный выпуск Swift 2)». IBooks.https://itun.es/us/utTW7.l

Разработчик API сможет отмечать наличие функций в Swift, используя:

available(iOS 8.0, OSX 10.10, *)
func useShinyNewFeature() {
    // ...
}

Выдержка из: Apple Inc. «Использование Swift с какао и Objective-C (предварительный выпуск Swift 2)». IBooks.https://itun.es/us/utTW7.l

Добавление этих маркеров к функциям, переписанным для Swift, кажется хорошим способом обеспечения обратной совместимости для Frameworks. Комбинация защита / доступность позволит пользователям этих структур по мере необходимости корректировать логику. Это облегчает мне задачу обработки как встроенных предупреждений, откатов API, так и макросов в целом.