Почему @unknown default (Swift 5) вызывает ошибку компиляции?
Думаю, я понимаю логику @unknown default, и прошу прощения за скриншоты вместо кода, но это единственный способ увидеть сообщения об ошибках в контексте.
Преобразовал проект в Swift 5. Он запускается, но получает это предупреждение, которое я понимаю:
Поэтому я позволил Xcode исправить это для меня и получил это:
Я изменил порядок заглушек (это работа в процессе), что снова радует компилятор:
Я делаю что-то, чего не должен, или это странное поведение компилятора?
Только для того, чтобы читатели могли видеть сообщения об ошибках в контексте.
Это известная ошибка СР-9920.
Ответы 2
Ошибка на среднем изображении выглядит как ошибка в быстром, и ее можно устранить, добавив точку с запятой в конце инструкции return.
Обычно компилятор ожидает, что @unknown default будет последним случаем. Проверьте @неизвестная документация от Apple, где они объясняют, почему он должен использоваться с последним регистром в переключателе, и многое другое по ссылке «неизвестные шаблоны» в следующей цитате:
@unknown may only be applied to default or a case consisting of the single pattern _. Even in the latter case, @unknown must be used with the last case in a switch. This restriction is discussed further in the "unknown patterns" section under "Future directions".
Чем средний пример не последний случай?
Пробовали ли вы в своем среднем примере поставить ; в конце return, например: return;?
Поздно вечером, не подумал об этом. Спасибо, только что попробовал, работает. Все еще думаю, что это ошибка Xcode, поскольку Swift делает большое дело об отсутствии точек с запятой.
Да, я думаю, это ошибка xcode с новыми изменениями Swift 5. Я добавил это как утверждение в ответ, чтобы убедиться, что оно правильно адресовано будущим читателям :)
«Все еще думаю, что это ошибка Xcode, поскольку Swift делает большое дело об отсутствии точек с запятой». Это неправда. Есть много других ситуаций, когда вам нужна точка с запятой после return, чтобы компилятор не подумал, что вы пытаетесь вернуть следующую строку.
Есть много ситуаций, когда голый return, за которым следует другая строка кода, заставляет Swift думать, что вы пытаетесь вернуть эту строку кода. Ситуация стала менее запутанной, чем раньше, потому что теперь есть хотя бы предупреждение, чтобы сообщить вам об этом (и ситуация возникает в гораздо меньшем диапазоне случаев, чем раньше):
@IBAction func doDismiss(_ sender: Any) {
return
self.presentingViewController?.dismiss(animated:true)
}
Этот код выглядит корректно, но не компилируется, в результате получается странная ошибка компиляции:
Value of optional type 'Void?' must be unwrapped to a value of type ‘Void'
К счастью, в этом случае причина странности теперь также раскрывается предупреждением (обычно):
Expression following 'return' is treated as an argument of the 'return'
Решение всегда состояло в том, чтобы добавить точку с запятой после return. Действительно, для тех из нас, кто использует Swift со времен Swift 1, добавление точки с запятой после голого return является практически рефлекторным действием, хотя в наши дни в этом обычно больше нет необходимости.
Ваша ситуация в основном случай той же проблемы. Проблема в том, что вы не получаете объяснительного предупреждения.
Есть ли документация по этому поводу? Потому что это похоже на ошибку xcode
Пример, который вы приводите, немного отличается — это return, за которым следует выражение, что является допустимым. Случай OP - это return, за которым следует оператор, который Swift должен иметь возможность обрабатывать как голый возврат, за которым следует оператор (вместо того, чтобы пытаться анализировать оператор как выражение). Это ошибка (СР-9920), что уже исправлено :)
@Hamish Я изменил пример на более убедительный.
@matt Это все еще выражение после возврата - рассмотрите другие случаи, когда оператор следует за возвратом, например, gist.github.com/hamishknight/b3014d64a8a9f820e29076ce0a211370, компилятор обрабатывает их правильно.
@Hamish Моя единственная цель - убедить ОП, что нет ничего необычного в том, чтобы писать return;, и что некоторые из нас просто делают это все время.
@matt Достаточно честно - я просто хотел указать, что в случае с OP не должно быть двусмысленности при синтаксическом анализе, он должен компилироваться без ошибок или предупреждений.
@Hamish Я думаю, что они должны компилировать все без ошибок или предупреждений.
Пожалуйста, не используйте изображения для вставки кода. Вставьте код напрямую.