ios_dev_187 Dec 4 2023 at 10:14

Топ 3 необычных вопроса на собеседовании iOS разработчика

Easy

5 min

Swift*Programming*

From sandbox

Comments 11

Krypt Dec 4 2023 at 10:47

Добавить сюда баги в диспетчеризации Swift:
https://stackoverflow.com/questions/34847318/swift-protocol-extension-method-dispatch-with-superclass-and-subclass
У нас будет отличный список того, почему Swift - самый упоротый язык из тех, что я встречал
Ну. по крайней мере теперь можно писать some/any Equatable, на это ушло всего каких-то 5 лет развития языка

ios_dev_187 Dec 4 2023 at 14:30

Ну они пишут у себя в доке, что легкочитаемый, а что там можно натворить с generic они умалчивают))))

Krypt Dec 5 2023 at 13:52

Ну читать его действительно легко. А вот писать...

Gummilion Dec 4 2023 at 12:02

Интересная вещь, попробовал выполнить такой код:

func firstFunc(name: any Equatable) {
    var temp = name
    temp = "world"
    NSLog("Hello \(temp)")
}

firstFunc(name: 3)

Думал, сломается, но temp сначала создается как Int, а после присваивания стал String - оказывается, в Свифте тип на лету может поменяться

FreeNickname Dec 4 2023 at 14:26

Тип не поменялся. У Вас же написано – any Equatable. Он и остался any Equatable. В этой переменной лежит значение любого типа, реализующего Equatable, и это единственная гарантия, которую такая декларация предоставляет. А то есть вон вообще вот такой срыв покровов)

var a: Any = "a string"
a = 5
a = "and a string again!"

Gummilion Dec 4 2023 at 15:11

Просто я полагал, что переменная при иницализации получает конкретный тип и он уже не может меняться. Выходит, что some так работает (по сути, синтаксический сахар для шаблона), а вот any - полностью динамический и конкретный тип может меняться (конечно, если удовлетворяет протоколу)

ios_dev_187 Dec 4 2023 at 16:34

Ну вот что это синтаксический сахар для шаблона - по сути да

ios_dev_187 Dec 4 2023 at 14:27

ну тут да, опять же потому что any написано, оно одобряет все, что подходит под Equatable

Krypt Dec 4 2023 at 14:32

Это нововведение в Swift 5.6, раньше действительно было нельзя написать temp = name

Вот так пишешь приложение (особенно в первые дни языка, портируя код с ObjC), и решаешь на свой интерфейс-теперь-протокол повесить Equitable. И у тебя не компилится половина кода, потому что твой протокол больше не "concrete type", а "generic constraint" и с практической точки зрения вообще не существует

FreeNickname Dec 4 2023 at 20:03

В первые дни языка вообще весело было) Swift 1 -> 2 и Swift 2 -> 3 оба раза морозили всю работу на несколько дней, идущих на то, чтобы проект хотя бы снова собирался :)

Krypt Dec 5 2023 at 13:47

Вообще первые пару лет я Swift старательно избегал, с критерием "я не коснусь его пока они в течении 2х мажорных версий не сломают ничего мажорного".
Формально этот критерий ещё не выполнен, ждём swift 6.

Имхо, Swift развивается очень медленно и очень хаотично. У нас сейчас 4 способа (включая "универсальные") описать keypath, а вот писать с его использованием в не-ObjC совместимые типы нельзя до сих пор. Мне тут периодически в спорах в достоинства Swift приводят рефлексию, которой по факту в Swift нет, всё, что есть - это bridging на ObjC рефлексию