«Что нового в Swift 2?» на примерах

[chiliec]

Спасибо за статью, отличные примеры! Вроде всё это и так знал, но всё равно такое ощущение что узнал что-то новое.

[Athari]

Мимо проходил. Количество ломающих изменений такое, будто переход не от 1.2 к 2.0, а от 0.5 к 0.6. Переписывать же невесело будет…

[WildGreyPlus]

Я не очень поняла ваше замечание. От 0.5 к 0.6 — это больше или меньше 1.2 от 2.0? Но, если по делу, то переходить очень легко — работает автоматическая миграция от Swift 1.2 к Swift 2.0 и работает очень хорошо, даже для больших проектов — все попробовала. Остаются только мелочи, которые легко поправить, если знаешь, как это должно быть.

[Athari]

В смысле сплошником радикальные изменения синтаксиса: не просто добавление ключевых слов или изменение обработки каких-то случаев, а полное изменение назначения ключевых слов, изменение синтаксиса вызова всех функций и тому подобное. Такие изменения характерны на ранних стадиях развития до первого релиза 1.0, а потом обычно стараются не ломать всё и сразу. Если свой проект можно прогнать через конвертировалку, то как быть, например, разработчикам библиотек, которые поддерживают несколько версий? Да и как в обычном проекте быть, если главная ветка перешла на новую версию, а старые ветки тоже надо поддерживать и мержить изменения? Короче, странно всё это видеть.

[WildGreyPlus]

Проходя мимо, вы, возможно, не в курсе, что на Swift 1.x вам никто и не предлагал разрабатывать промышленные библиотеки, хотя смельчаки, конечно, находились, потому что это совершенно новый язык и никто не знал, куда он «вывернет». Были прогнозы, что он вообще уйдет в сторону функционального программирования. Но прошел год, когда весь мир участвовал в отладке Swift, и сейчас мы получили не только новый язык Swift 2, но и новые концепции программирования — помимо Объектно-Ориентированного Программирования (OOП), которое было там изначально, помимо элементов Функционального Программирования, еще и Протоколо-Ориентированное Программирование. Кроме того язык очень краткий и очень красивый. Программирование на нем — очень увлекательное занятие. Так что странного ничего нет. Пробуйте. Я думаю он и вас не оставит равнодушным.

[Athari]

А, понятно, «1.0» по смыслу был «0.5», а «2.0» — что-то типа «0.9». Тогда всё встаёт на свои места. :) Традиции расстановки цифр в версиях разные, да и цифры конкурентов догонять надо… Вообще, я сторонник идей semver.org.

[WildGreyPlus]

Почему забили? Нет, они обещали к концу 2015 года. Все будет. Они очень заинтересованы в продвижении Swift. По-моему даже Windows будут что-то реализовывать у себя для разработки приложений на Swift. Если вы заметили, то Microsoft на последнем Keynote первыми демонстрировали разработку Microsoft Office для iOS. Это необычно.

[xGromMx]

Что-то похожее уже есть) www.elementscompiler.com/elements/silver

[Athari]

А какие у свифта киллер-фичи кроме совместимости с Obj-C?

[WildGreyPlus]

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

[WildGreyPlus]

Почему нельзя перемешивать? Пожалуйста, можете использовать любые Objective-C классы в Swift проектах, для облегчения доступа к ним в Xcode 7 добавлены 3 новые возможности для Objective-C:
— nullability;
-lightweight generics;
__kindof types.
И, наоборот, можете выставить свой Swift класс для использования в Objective-C.
В Swift 2 сильно улучшено взаимодействие с С-функциями и теперь указатели на C-функции — это просто специального вида замыкания, аннотируемые атрибутом @convention.
Я хочу об этом писать во второй части.

[EvilPartisan]

Возможность подобного смешивания наложила бы существенные ограничения на сам язык и потянуло бы соответствующие недостатки из старого языка. Всё-таки Objective-С это надстройка над C. А Swift — это именно другой язык с другой внутренней архитектурой. Совместимость такого рода как реализована сейчас, на мой взгляд, является самой оптимальной. У вас есть возможность использовать языки разного уровня и типа в одном проекте и достаточно прозрачно их сшивать — и это уже очень здорово!
Да и вообще плохой это тон — мешать код разных языков в одном файле.

[EvilPartisan]

Разумеется это не киллер-фича, но это критически необходимая вещь для выживания любого нового языка.
Вообще в индустрии так сложилось, что каждый крупный (да и не очень крупный) игрок старается или вынужден разрабатывать свой собственный язык. И Apple просто сделала очередной необходимый шаг. Можно обожать ObjC сколько угодно, но давайте по-честному всё-таки он уже устарел, так что Apple даже несколько затянула с этим и вынуждена сейчас форсировать события. Поэтому мы наблюдаем такие частые и сильные изменения в языке.
Как бы то ни было, лично я считаю, что Swift может и не лучше других модных ныне языков (Go, C#, Rust и тд) но по крайней мере не хуже и благодаря поддержке Apple имеет хорошие шансы занять существенную долю рынка даже за пределами инфраструктуры Apple.

[YHVHvx]

А вот это вы зря! Только что поставил и погонял Beta релиз Xcode 7.1 (Build: 7B91b) с поддержкой Swift 2.1.
В версии 2.1 добавили возможность использования си кода без всяких бриджей (наконец то избавились от костылей что юзали раньше) :)

func xyz() throws {
   let f = fopen("x.txt", "r")
   defer { fclose(f) }
   try foo(f)                    // f is closed if an error is propagated.
   let f2 = fopen("y.txt", "r")
   defer { fclose(f2) }
   try bar(f, f2)                // f2 is closed, then f is closed if an error is propagated.
}                                // f2 is closed, then f is closed on a normal path

Более подробно можно почитать тут: https://developer.apple.com/library/prerelease/ios/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.html

Apple делает правильные шаги для того, чтобы заменить Objective C на более перспективный и мощный язык программирования; и как мне кажется делает это весьма успешно ;)

[YHVHvx]

ну так унификация типов же.
и ведь let f = fopen(«x.txt», «r») намного лучше выглядит чем FILE* f = fopen(«x.txt», «r»);
алсо никто не мешает определять типы вручную:

let f:UnsafeMutablePointer<FILE> = fopen("x.txt", "r");

[EvilPartisan]

Это не си код, это как раз самый обычный swift-код.

[WildGreyPlus]

Конечно, это Swift код, но обращение к С-функциям напрямую, без всяких UnsafeMutablePointer.
Вот еще один пример — вызываем функцию сортировки qsort из библиотеки strdlib.h


хотя сигнатура у нее очень накрученная

[EvilPartisan]

Предыдущая версия свифт вела себя также, «без всяких UnsafeMutablePointer», разве что try и defer еще не было.
Я не понимаю о чем вы спорите, человек хотел вставлять си код, внутрь кода Свифт, вроде того как работают ассембленые вставки в си. Это невозможно сделать чисто технически, а вызывать сишные функции можно было изначально.

[EvilPartisan]

Даже не как вставки, а прям всплошную, что вообще безумие. (0_о)

[vba]

Спасибо за обзор.

У меня небольшой вопрос по синтаксису.

case let (.Some(username), .Some(password)):
    print("Success!")

Скажите пожалуйста а здесь .Some это своего рода вызов статического метода из предварительно импортированного пространства имен.
Типа статического импорта в Java или C#?

[WildGreyPlus]

Swift имеет тип Optional, который означает, что либо у вас нет значения (None), либо у вас есть некоторое значение (Some). Так как Swift разрешает иметь для перечислений enum ассоциированные значения, то Optional тип можно представить с помощью перечисления enum так:

enum Optional {
    case None
    case Some(T)
}

Когда вы задаете Optional значение, то добавляете к типу знак вопроса ?

 var username: String?
 var password: String?
 
username = .Some("Alex")
password = .None

Но как только вы это совершили, вы будете обращаться со своими переменными username и password как перечислениями — они оказались «завернутыми» в Optional тип.
Для извлечения ассоциированных значений (String, а не String? ) используется оператор switch



Вместо того, чтобы каждый раз помнить, что нужно использовать .Some и .None, предложен синтаксический сахар


В результате вы общаетесь только со своим идентификатор username и nil и знать ничего не знаете о .Some и .None.

[vba]

Да это я все понял, спасибо. Вопрос был немного о другом, что именно означает точка перед .Some это логически должно быть эквивалентно Optional.Some. Просто мне, человеку с багажом Java/C# точка бьет в глаз, вот и мучаю себя вопросом эквивалентно ли это статическим импортам.

[WildGreyPlus]

Точка означает обращение к перечислению. Да это эквивалентно Optional.Some. Как к нему обратиться в Java?

[WildGreyPlus]

Вы же в switch указали переменную, по которой будете «переключаться»? Компилятору уже известно, что она Optional. Осталось только указать значения перечисления (с возможностью извлечения ассоциированных значений). И это указывается с применением точки.

[DmitrySpb79]

Спасибо за статью, интересно. Пишу на Swift, но скорее в С/ObjC-стиле, так что узнал много нового.

Вообще, что в ObjC что в Swift, огорчает что это уж больно нишевые языки, которые практически не имеют хождения за пределами экосистемы Apple (но видимо это вечная участь iOS-разработчиков, увы). Уж лучше бы в Apple вторым языком яву выбрали :)))

[EvilPartisan]

У Swift как раз есть шансы выбраться за пределы этой экосистемы. Тут больше роли играет не сам язык, а политика компании.

[WildGreyPlus]

Если хотите писать приложения в соответствии с логикой Swift, то полезно посмотреть русский перевод стэнфордских лекций «Developing iOS 8 Apps with Swift» на сайте «Разработка iOS + Swift + Objective-C». Там профессор учит писать приложения именно в соответствии с логикой Swift (Наблюдатели Свойств, вычисляемые свойства, отложенная инициализация и т.д.).
По поводу «нищевости» — увидим, по крайней мере Apple сейчас предпринимает огромные усилия, чтобы выйти из этой ниши. Даже разработала методику обучения Swift в школах. Кстати, по своим возможностям Swift превзошел Java, хотя бы в плане функционального программирования.

[fiveze]

Это делает guard естественным способом проверки нефатальных предварительных условий без использования «пирамиды сметри»

А что за «пирамиды сметри»? Ничего не нагуглил по этому термину.

[WildGreyPlus]

Если вам нужно парсить JSON данные

{
  "stat" : "ok",
  "blogs" : {
    "blog" : [
      {
        "needspassword" : true,
        "id" : 73,
        "name" : "Bloxus test",
        "url" : "http:\/\/remote.bloxus.com\/"
      },
      {
        "id" : 74,
        "name" : "Manila Test",
        "needspassword" : false,
        "url" : "http:\/\/flickrtest1.userland.com\/"
      }
    ]
  }
}

в модель

struct Blog { 
  let id: Int 
  let name: String 
  let needsPassword : Bool 
  let url: NSURL
}

то в строго типизированном языке, как Swift, получается множество вложенных if

func parseBlog(blogDict: [String:AnyObject]) -> Blog? { 
  if let id = blogDict["id"] as NSNumber? { 
    if let name = blogDict["name"] as NSString? { 
      if let needsPassword = blogDict["needspassword"] as NSNumber? { 
        if let url = blogDict["url"] as NSString? { 
          return Blog(id: id.integerValue,
                      name: name,
                      needsPassword: needsPassword.boolValue,
                      url: NSURL(string: url)
                      )
        }
      }
    }
  }
  return nil
}

Это и называется «pyramid of doom» (пирамида смерти), она характерна не только для Swift. В Google надо искать «pyramid of doom».