506 страниц «The Swift Programming Language» асилены за сегодя.
Начинал делать заметки, но по скорости не успел.
Вот какие‑то ошметки:
operator precedence отличается от C
Extensions — звериный оскал закрытых исходников
Заебись, а когда инициализируешь stored properties с помощью closure, нужно это свойство объявлять как lazy, чтобы внутри closure был доинициализированный self. (потому что @lazy доступны только после полной инициализации)
Интересный трюк с пропусканием «не до конца инициализированного» self. Сначала инициализируем все что можно, а остальное определяем как optionals, после чего отправляем self в плавание. А на стороне приемника можно зафигачить unowned reference, например. Наверное, имеет смысл вот так и записывать stored properties: вначале идут все обязательные, а потом пустая строка и implicitly unwrapped optionals. Это будет таким толстенным намеком, что второй блок properties используется после утекания «недоинициализированного» self.
Непонятно, почему именно пользователь должен расставлять ключевые слова convenience для initializers. Следуя их же правилу, designated initializers всегда делегирует вверх, а convenience — across. Так что если initializer звет designated initializer, то он обязан быть convenience. Это и компилятор может определить, не? Зачем писать руками?
Arrays в свифте ваще какие‑то укуренные. Если длина не меняется (но меняются элементы), все ссылки на массив указывают на одну и ту же последовательность. Если длина меняется, реф на Array к которому было сделано изменение, начинает указывать на копию. Ну то есть это понятно с точки зрения внутренней механики, но нахуя пользователю‑то давать видеть весь этот писец. Сделали бы два типа, Array и ХитровыебанныйArrayУКоторогоВидныПотроха.
Забавная у них иммутабельность.Dictionary иммутабелен в нормальном смысле, а вот Array — нельзя менять длину, а содержимое — можно. Короче, они явно не держали в голове immutability‑first. Тут постоянно оперируют с состоянием.
−1
