Многоликие функции Swift

[@TAURUSiv43]

Поставил плюс вашей статье за перевод, но вот не понимаю тягость современных программистов-блоггеров к пересказу документации. Apple выпустила на столько детализированную и лаконичную книгу, что она читается за 2 часа. Кроме того, она так отлично разбита на главы, что часто можно просто перейти к интересующей главе. Но не смотря на это выходит какое-то невообразимое количество статей в англоязычном сегменте о том как сделать сабкласс на Swift, let и var в Swift, коллекции в Swift.

[@WildGreyPlus]

Я бы не отнесла эту статью к разряду просто пересказа документации. В документации все есть, но в разных местах: часть — в Functions, часть (метод init) — в Classes and Structures, Enumerations. Для тех, кто пришел с Objective C, где все было просто, есть некоторая путаница, когда в методах нужно внешнее имя, а когда — нет. Здесь она собрала все в одном месте. Мне показалось это полезным. Кроме того, следует обратить внимание на автора поста Natasha Murashev — у нее очень интересные посты — короткие и по делу. И, вообще, она сейчас «звезда» Swift сообщества и выступает на всех Swift мероприятиях.

[@naum]

Другое замечание относительно variadic параметров: variadic параметр должен быть последним параметром в вашем списке параметров!

Впервые читаю про синтаксис Swift'а и на этом месте сделал грустишку. Простейший для реализации синтаксиса момент, почему его игнорируют во многих языках? В этом плане впервые порадовало Ruby (у кого-то могло быть иначе), конечно. Представим себе прототип функции (абстрактного языка в вакууме) — «func(param1, param2, ...variadic_param..., param4, param5)», вычленить массив параметров в рамках variadic_param проще пареной репы — взяли массив всех параметров, убрали два именованных спереди и сзади — остальное variadic. Ну и запрет на два variadic подряд по вполне понятным причинам и прежде всего из-за логики.

[@Athari]

Предлагаемая вами фича не сочетается со значениями аргументов по умолчанию и некоторыми другими фичами. Функции с переменным числом аргументов даже при текущих ограничениях способны приводить к неоднозначным и неочевидным ситуациям при перегрузке функций.

[@naum]

Да, с перегрузкой согласен. Только что коллега-рубироид подсказал, что в рубях при этом нет перегрузки в принципе.

[@WildGreyPlus]

Swift — язык молодой (декларирован 4 июня 2014 года на WWDC — 2014) и пока все время меняется, даже концептуально. Есть проблемы и ограничения, но Apple team их устраняет от релиза к релизу. Пока, конечно, много критики, но уверена — все сделают в «лучшем » виде, хотя и не сразу.

[@alexkbs]

Меня мучает вопрос: как в Swift сделать функцию, которая возвращает функцию которая возвращает функцию?

[@WildGreyPlus]

func add (a1:Int, a2:Int) ->Int {return (a1 + a2)}
func multiply (a1:Int, a2:Int) ->Int {return (a1 * a2)}

func funcReturnFunc (funcOperation: (Int,Int) -> Int) -> (Int, Int) ->Int {
   
    return funcOperation
}

func funcReturnFunc2 (funcOperation: (Int,Int) -> Int) -> (Int, Int) ->Int {
    return funcReturnFunc(funcOperation)
}

let returnedFunction = funcReturnFunc2 (multiply)
let returnedFunction1 = funcReturnFunc2 (add)


returnedFunction(5,6)    // Получим 30 на playground
returnedFunction1(5,6)  // Получим 11 на playground

<source>

[@alexkbs]

Вы сделали функцию, которая возвращает функцию. Как это сделать в книжке в примерах пишут. А нужна функция, которая возвращает функцию, и каковая тоже возвращает функцию. Не вижу как синтаксически это оформить без мудреного typealias.

Извините за мой JavaScript:

var test = function (i) {
    return function (j) {
        return function (k) {
          // oh finally!
          return i + j + k;
        };
    };
};

test(1)(2)(3); // == 6

[@WildGreyPlus]

Вы имели ввиду каррированные функции ( curried functions).
Их можно реализовать в Swift двумя способами:

func add (i:Int, j:Int, k:Int, l:Int) -> Int {return(i + j + k + l)}

// 1-  ый метод

func curry<A,B,C,D,R>(f: (A,B,C,D) -> R) -> A -> B -> C -> D -> R {
    return { a in { b in { c in { d in f(a,b,c,d) } } } }
}

let sum4 = curry (add )

// 2-  ый метод (curried function in Swift)

func sum4Swift(i: Int)(j:Int)(k: Int)(l:Int) -> Int {
    return add(i, j, k, l)
}


sum4 (1)(2)(3)(5)                     // playground 11
sum4Swift (1)(j: 2)(k: 3)(l: 5)    // playground 11

[@alexkbs]

Однако сейчас все получается.

func chained(i: Int) -> (Int) -> (Int) -> Int {
    return { (j: Int) -> (Int) -> Int in
        return { (k: Int) -> Int in
            return i + j + k;
        }
    }
}

chained(1)(2)(3)

[@WildGreyPlus]

Можно так:

func chained (i:Int) -> Int-> Int -> Int {
    return { j in
        return { k in
            return i + j + k;
        }
    }
}

chained(5)(6)(7)  // playground 18

[@alexkbs]

Так гораздо лучше. Спасибо за это.

[@notxcain]

Проблема встроенных optionals в том, что для них нет монадических комбинаторов. Но уже есть swiftz :)

[@WildGreyPlus]

«Магическое» будущее Swift описано в замечательных статьях ALEXANDROS SALAZAR The Culmination: Final Part (есть перевод «Кульминация — финальная часть.),

[@WildGreyPlus]

По поводу «вывода типов» и «похожести» Swift на Haskell есть ряд интересных статей Tony DiPasquale:

«Эффективный JSON c функциональными концепциями и дженериками в Swift.» (перевод) — оригинал «Efficient JSON in Swift with Functional Concepts and Generics».
«Реальный мир парсинга JSON.» (перевод) — оригинал «Real World JSON Parsing with Swift.»
«Парсинг вложенных JSON и массивов в Swift.» (перевод) — оригинал «Parsing Embedded JSON and Arrays in Swift.»

[@WildGreyPlus]

Ну к этому можно привыкнуть, зато как удобно искать методы в Xcode

<img src="" alt=«image»/>

[@WildGreyPlus]

Sorry, это я действительно не в тему.
Но вас-то что раздражает?

Методы выглядят абсолютно одинаково, что в Swft, что в Objective-C

   override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int { } //Swift

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {} // Objective-C

  override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {} //Swift

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {} //Objective-C
<source>

[@alexkbs]

Методы в Obj-C очень литературные, читается легко и понятно.
В Swift возникает мешанина скобок и двоеточий, которая не сказать прямо что помогает.

[@WildGreyPlus]

Согласна. Но сейчас держит Cocoa Touch, написанная на Objective-C: весь API оттуда. Если перепишут Cocoa Touch на Swift, то, возможно, будет другой API.

[@YGeorge]

а планируют ли вообще переписывать, не знаете случайно?

[@WildGreyPlus]

Конечно, не знаю. Но думаю, что будут, так как слишком много «некрасивостей» в Swift вылезает из Cocoa Touch на Objective-C.

[@YGeorge]

ну может встречали где-то в блогах инфу такую )
ну что-же, нам остается только надеяться и ждать.

[@WildGreyPlus]

А зачем ждать? Все работает. Есть книжка «Using Swift with Cocoa and Objective-C». Связи Swift c Objective-C отработаны более- менее. Весь Cocoa Touch API подстроен для доступа из Swift. Вперед. Ну а эстетика может подождать. Сам по себе Swift — замечательный.