Стрижиное

[migmit]

Ну что, попробовал я таки этот Swift. Скачал бету XCode, распаковал, запустил. И доложу я вам: это штука с огроменным потенциалом. В смысле, ни фига не работает.

Я, честно сказать, думал проверить ихние дженерики своим любимым тестом, который C++ не прошёл, а, скажем, Java — вполне. Наивный.

Дело в том, что когда вы пишете код в XCode, то вам показывают места ошибок. Это очень удобно. Однако делается это путём запуска компилятора в фоне. А компилятор сей страдает падучей. И когда он сегфолтится — а это происходит довольно часто — весь XCode вылетает нафиг.

Дальше ещё веселее. Вы запускаете XCode заново, он восстанавливает тот же файл, снова прогоняет его через компилятор, тот снова сегфолтится, и XCode снова вылетает.

Я не смог запилить такой код, который проверял бы мой тест и при этом не сегфолтился.

Так что пока ихняя бета (которая beta than nothing) отправляется в корзину. Увы.

Comments

[sergey_cheban]

Итого:
1. Должны генериться два вектора.
2. Длина векторов будет известна только в рантайме.
3. Падать должно в compile-time.
Увы, чудес не бывает. Так что либо мы вместо пары векторов на самом деле генерируем что-то типа vector<pair<T,T>> (а то, что он в некоторых языках выглядит не как вектор пар, а как пара векторов - это только синтаксический сахар), либо имеем проверку в рантайме.

[migmit.livejournal.com]

А теперь посмотри по ссылке. Там сделано для C#. Для Java это переписывается практически дословно. В хаскеле это совсем тривиально, в OCaml необходимо немного поприседать.

Идея в том, чтобы сделать последовательности разной длины значениями разных типов. Тогда наша функция может быть дженериком, который принимает два аргумента любого — но одного и того же — типа, если только он соответствует некоторым ограничениям (например, экспортирует определённый интерфейс).

Как следствие, набор типов, которые нужно будет использовать в рантайме, становится неограниченным — но с настоящими дженериками это не страшно. А вот шаблоны C++ не справляются. И Rust-овские "дженерики" не справляются (потому что они там шаблоны, на самом деле, только без возможности частичной специализации).

[sergey_cheban]

Да я смотрел по ссылке. Идея в том, что либо мы должны как-то объяснить компилятору, что у нас переменные одного типа (неизвестного, поскольку длина векторов неизвестна, но одного), либо нам придётся-таки делать проверку в рантайме. Так вот, чтобы поддерживать одинаковость типов, тебе приходится везде обрабатывать вектора вместе. А в этом случае разница между парой векторов и вектором пар исчезает.

PS. Я в Москву на Мейерса еду, так что не удивляйся, если пропаду дня на три.

[migmit.livejournal.com]

> мы должны как-то объяснить компилятору, что у нас переменные одного типа

Да.

> А в этом случае разница между парой векторов и вектором пар исчезает.

Не согласен.

Автор scalarProduct может вообще не рассчитывать на подобное использование. Он, может, вообще ожидал, что функция будет вызываться только для векторов с заранее известной длиной (и в этом случае шаблонов вполне хватило бы). Сделал, запихал в библиотеку — готово.

А мы взяли эту библиотеку и применили её вот таким образом.

[sergey_cheban]

> Автор scalarProduct может вообще не рассчитывать на подобное использование.
Я не уверен, что лёгкость использования библиотек/микроскопов не по назначению может считаться аргументом в пользу чего-либо. Так что давай всё-таки предположим, что автор scalarProduct знал, что делал.

А если нет, то я предложу другую задачу: взять два вектора из файлов, в рантайме проверить, что их длины равны, если не равны - ругнуться, а если равны - перемножить. Рискну предположить, что такое, в зависимости от языка, либо не делается вообще, либо делается с неявным использованием RTTI (т.е. с overhead'ом).