Pull to refresh

Comments 32

Вопрос: Swift 3 — будет c длительным временем поддержки? И будет ли обратная совместимость в Swift 4?
Озвучивалось это?
Да. Обещают к весне 2017 обеспечить ABI стабильность и возможность работы с Swift 4 и Swift 3.
Swift Programming Language Evolution
Поставлена как первостепенная задача.

Тогда не понятно почему 4.0
Смена мажорной версии обычно говорит об отсутствии обратной совместимости. Простой вопрос. Будет ли 4.0 компилировать 3.* без изменений и "битой семантики"?

Я не большой специалист по компилятором, но приведу дословно как ставится первостепенная задача:
to provide source stability for Swift 3 code and to provide ABI stability for the Swift standard library.
Это то, что вы имели ввиду?

Благодарю, я читал эту фразу. Проблема в том, что эта фраза противоречит действиям Эппл, если исходить из общепринятых практик. Общепринятые практики (semver) говорят, что смена мажорной версии — сигнал об обратной несовместимости. Эппл поменяли мажорную версию — по логике 4-я должна иметь проблемы с компиляцией 3-й. Но исходя из их заявления это не так. Тогда зачем было менять мажорную версию? Короче, я подозреваю что разработчикам под экосистему Эппл таки придётся в очередной раз переписывать код.

UFO just landed and posted this here
Насколько я помню, задача — обеспечить компиляцию 3 и 4 в одном проекте, при этом 4 допускает ломающие изменения.
Вы путаете тёплое с мягким. semver – отличная вещь, но зачем её пихать там где она не нужна? Semver прекрасно подходит для версий библиотек, чтобы сразу было понятно, возникнут проблемы при обновлении зависимостей или нет, и можно было установить ограничения на зависимости в настройках проекта, и быть уверенным (в определённых пределах), что при обновлении ничего не сломается.
С семантической и прикладной точки зрения зачем semver в версии языков программирования? Спрашиваю на полном серьёзе, т.к. не понимаю юзкейс (в отличии от использования с библиотеками, как я описал выше).
Swift 4 и последующие версии будут продолжать методично ломать ваш код :)
Под ABI совместимостью имеется в виду, что можно будет линковать фреймворки, написанные на разных версиях Swift, начиная со Swift 4.
То есть не будет такой ситуации, как с Python, когда вы не можете мигрировать на новую версию языка только потому, что все либы заточены под старую. Не компилируется под новой версией Swift? Ну и ладно, укажу в настройках, чтобы только этот модуль компилировался под старой Swift.
Редко встретишь языки без обратной совместимости, кроме Python 2/3 даже не знаю. Сколько уже боли слышал от коллег iOS-ников
Отсутствие обратной совместимости положительно сказывается на развитие языка. Конечно обидно, что существующий код перестанет компилироваться, но обратная совместимость всегда имеет отрицательные последствия для будущего языка.

Проблема в том, что обычно мажорный релиз языка выпускают с большой подготовкой и редко — с промежутком лет эдак в 10. Питон, как пример, до сих пор тянет 2 ветки. Эппл просто выкидывает на помойку часть того что было ранее. Это не добавляет энтузиазма.

Swift 3 очень даже добавил энтузиазма. Язык великолепен, и несмотря на то, что нас так пугали, что Swift 3 слишком далеко отстоит от Swift 2, переход на Swift 3 оказался очень легким и приятным, а ведь там поменялись практически все имена функций и не только. Думаю, что переход на Swift 4 вообще будет без проблем, потому что именно в Swift 3 они далеко «отъехали» от Objective-C.
Swift 3.0 по сравнению с Obj-C, как iPhone 6 после iPad 2, как Чехов после Толстого.

Изменения в интерфейсе самого Swift вызывают трудно сдерживаемое одобрение.
Если код перестает компилироваться, то разработчик начинает терять деньги, а расходы на поддержку софта увеличиваются. И спрашивается, зачем переходить на Swift? Чтобы иметь развлекуху, описанную выше? И при этом нет никакой гарантии, что «ритуал» не придется повторить…
Вы не поняли о чем идем речь или не до конца дочитали. Код-то как раз компилируется и миграционный «робот» делает для этого все возможное и фантастически невозможное, но в некоторых случаях код можно сделать более эффективным и в статье показано по каким направлениям нужно смотреть.
Так это-то я понял, я не понимаю, зачем это надо делать вообще? То есть, исполользовать такой язык, с которым нужно возиться после каждого обновления XCode. Вот, например, есть 100 приложений по 50 экранов на Swift, это каждое нужно оптимизировать? Даже если на одно приложение потратить день, то получится нужно выбросить 100 дней, минимум, только для того, чтобы это снова начало компилироваться, я уже не говорю про новые баги. И для сравнения можно взять те же приложения, но на Objective-C. Их просто перекомпилировал и они работают. Поэтому, пока у Swift не будет обратной совместимости, рассматривать его, как нормальный язык программирования, а, следовательно, и писать на нем серьезные приложения, нельзя. Мне так кажется…
Вы пробовали программировать хоть что-нибудь на Swift? Уверена, что нет. Если вы напишете что-то на нем, вы уже не перейдете обратно на Objective-C никогда, даже если вам придется переходить от версии к версии. Я очень люблю Objective-C, но ни один новый проект не начну на Objective-C. И хотите вы этого или нет, а Objective-C уйдет. Поэтому вместо того, чтобы вести бессмысленные подсчеты, учитесь программировать на Swift. Желаю удачи.
Вы перейдёте обратно на Obj-C, когда вам придётся разрабатывать какую-нибудь библиотеку с закрытыми исходниками из-за отсутствия ABI stability. Это я не спорю, это я жалуюсь :( Эх, скорее бы весна… Ну или осень, в зависимости от того, когда ABI stability будет :)
Конечно я писал на Swift. Но в виду наименьшей геморройности, предпочитаю Obj-C. Но другим свое мнение не навязываю, а просто спрашиваю зачем со Swift связываться ввиду вышеописанных накладных расходов? Может я что=то упустил?
P.S. За удачу благодарствую. Взаимно. :)

Бесспорно, имеет. Но не каждый же год её ломать.

XCode тупо не может сконвертировать мой проект, виснет и кладет всю систему, памяти утекает на 50+ gb.
Может что-то не так с проектом? Памяти 50+ gb?
Я имел в виду, что XCode столько занимает в оперативке, а не мой проект.
Где продают Mac с оперативной памятью 50 gb?
Понятное дело она сжатая, но менеджер процессов показывает именно столько.
Жаль я не записал все перлы от этого автоматического мигратора Swift 2.2 -> Swift 3.0, когда конвертировал несколько больших проектов… Выложил бы их сейчас сюда. Самое безобидное, что вспоминается:

// Swift 2.2
var parameters =  [String: AnyObject]()
parameters["skip"] = 0

// Swift 3.0
var parameters = [String: Any]()
parameters["skip"] = 0 as Any? // wtf?


Так что да, миграция с автомигратором Xcode — это очень увлекательное занятие.
У вас устаревшая информация.
Xcode 8.1 ведет себя по-другому
var parameters =  [String: AnyObject]()
        parameters["skip"] = 0 as AnyObject?


Если вы использовали Xcode 8.0, то я вас понимаю, там действительно было ошибок и предупреждений на два экрана.
Я специально написала про версию Xcode 8.1 и 8.2 — все кардинально изменилось.
Если дадите ссылку на ваш код на Swift 2.2 — буду признательна. Просто хочу убедиться, что миграционный «робот» в Xcode 8.1 и 8.2 улучшился существенно.
Это действительно увлекательно.
Где по другому-то, в вашем примере? Неужели вы считаете конструкцию 0 as AnyObject? нормальной?
В вашем примере словарь, который был в Swift 2 [String: AnyObject] превращается в Swift 3 в словарь [String :Any], что в зависимости от дальнейшего кода может привести к ощибке на этапе выполнения.
В моем случае словарь как был [String: AnyObject] так и остался [String: AnyObject], что не приведет к ошибке при выполнении кода. И это различие важно для выполнения кода без ошибки.
Да, код 0 as AnyObject? мне не нравится, но я же сказала, что «робот» слишком озабочен тем, чтобы сохранить код работоспособным. Иногда это излишне, как в этом случае и в случае приведенном в статье, когда он вставляет кучу лишнего кода, лишь бы сохранить вам возможность сравнивать Optional значения. Поэтому требуется ручная работа.
Зная такую логику работы миграционного «робота», ручные правки кода сделать легко.
Кстати, миграционный «робот» вас поправляет.
Вы определили «значение» для словаря как AnyObject (то есть ссылочный тип), так зачем же задать «0» (value тип)?

В Swift 3 независимо от миргационного «робота» (так компилятор работает) правильный код такой:

var parameters =  [String: AnyObject]()
 parameters["skip"] = 0 as AnyObject?


или

var parameters =  [String: Any]()
 parameters["skip"] = 0 


Второй вариант мне кажется больше логичным.
Sign up to leave a comment.

Articles