trait + impl vs class , навеяно Rust'ом

Цитата applegame @ 08.07.15, 11:27

Для меня это будет полиморфная функция bar.

Возможно. А может ты хотел вызывать метод того же класса, в котором пишешь метод foo, а может еще чего-нибудь.

Цитата

Что значит полиморфный тип? Кто-нибудь может дать внятное определение

Вот, например
https://www.haskell.org/tutorial/goodies.html

Цитата

Haskell also incorporates polymorphic types---types that are universally quantified in some way over all types. Polymorphic type expressions essentially describe families of types. For example, (forall a)[a] is the family of types consisting of, for every type a, the type of lists of a. Lists of integers (e.g. [1,2,3]), lists of characters (['a','b','c']), even lists of lists of integers, etc., are all members of this family. (Note, however, that [2,'b'] is not a valid example, since there is no single type that contains both 2 and 'b'.)

Добавлено 08.07.15, 12:04
Ну и полиморфная функция аналогично.

Цитата D_KEY @ 08.07.15, 12:03

Вот, например

И что именно здесь не подходит к шаблонам? Ну кроме названия языка

Сообщение отредактировано: applegame - 08.07.15, 12:09

Цитата applegame @ 08.07.15, 12:06

Цитата D_KEY @ 08.07.15, 12:03

Вот, например

И что именно здесь не подходит к шаблонам?

Я уже говорил 100500 раз. Инстанс шаблона зависит от конкретных значений параметров шаблонов. Тип совершенно никак не связан с шаблоном, который его породил. Спор абсолютно бесполезен, это давно видно.

Цитата D_KEY @ 08.07.15, 12:10

Я уже говорил 100500 раз. Инстанс шаблона зависит от конкретных значений параметров шаблонов. Тип совершенно никак не связан с шаблоном, который его породил. Спор абсолютно бесполезен, это давно видно.

В твоей цитате ничего нет об инстансах, конкретных значениях и т.д. и т.п. Ты мне напиши, что-то вроде: "полиморфный тип - это нечто обладающее такими-то свойствами и вот это свойство отсутствует в шаблонах C++".

Сообщение отредактировано: applegame - 08.07.15, 12:13

Цитата applegame @ 08.07.15, 12:12

В твоей цитате ничего нет об инстансах, конкретных значениях и т.д. и т.п.

Ты спросил, что такое полиморфный тип.

Цитата

Ты мне напиши, что-то вроде: "полиморфный тип - это нечто обладающее такими-то свойствами и вот это свойство отсутствует в шаблонах C++".

Это следует из определения параметрического полиморфизма. В котором четко сказано, что зависимости быть не должно.

Добавлено 08.07.15, 12:16

Цитата applegame @ 08.07.15, 12:12

В твоей цитате ничего нет об инстансах, конкретных значениях и т.д. и т.п.

Можешь начать с того, что полиморфный тип - это тип, а полиморфная функция - это функция. Шаблон типа/функции в С++ не является типом/функцией.

Сообщение отредактировано: D_KEY - 08.07.15, 12:16

Цитата D_KEY @ 08.07.15, 12:14

Это следует из определения параметрического полиморфизма. В котором четко сказано, что зависимости быть не должно.

Зависимости кода от типа? Ну дык в шаблоне без специализации или перегрузки один код для всех типов. Ты говоришь, что компилятор C++ создает в бинарном конечном файле несколько вариантов функций. Ну дык я тебе гарантирую, что компилятор Хаскеля в случае функции суммирования двух переменных тоже создаст несколько разных функций в бинарном файле в зависимости от типа.

Добавлено 08.07.15, 13:15

Цитата D_KEY @ 08.07.15, 12:14

Шаблон типа/функции в С++ не является типом/функцией.

Правда? Ну тогда скажи мне bar- это функция или шаблон? И является ли тип переменной b - типом?

int a = bar(b);

Добавлено 08.07.15, 13:19
Кстати, считаешь ли ты функцию printf - параметрически полиморфной?

Сообщение отредактировано: applegame - 08.07.15, 13:19

Цитата D_KEY @ 08.07.15, 11:21

Там в ЖЖ код на C#, на дженериках.

Я его видел. Но зациклился на определении List через enum.

В любом случае, не получится. Раст тоже будет бесконечно пытаться выводить типы.

Все, ща D_KEY заявит, что в Rust нет настоящего полиморфизьма! А причина очевидна: В Rust нет виртуальной машины, поэтому он не умеет инстанцировать свои дженерики в run-time как C#. Теперь по D_KEY получается еще, что в Rust и дженериков-то нет, а есть недошаблоны. Буга-гашеньки.

Цитата applegame @ 08.07.15, 13:14

Ну дык в шаблоне без специализации или перегрузки один код для всех типов.

Не будет.

Цитата

Ты говоришь, что компилятор C++ создает в бинарном конечном файле несколько вариантов функций.

Нет, я говорю о том, что он генерирует функции/типы(сущности языка).

Цитата

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

Это аспект реализации. Если бы он так не делал, ничего бы в языке не поменялось. А в C++ поменялось бы. В этом и разница.

Цитата

Цитата D_KEY @ 08.07.15, 12:14

Шаблон типа/функции в С++ не является типом/функцией.

Правда? Ну тогда скажи мне bar- это функция или шаблон? И является ли тип переменной b - типом?

int a = bar(b);

Какое это имеет отношение к теме?

Цитата

Кстати, считаешь ли ты функцию printf - параметрически полиморфной?

Классическую сишную? Нет.

Цитата applegame @ 08.07.15, 13:14

Ну дык в шаблоне без специализации или перегрузки один код для всех типов.

Нет, не один. Ещё раз: Стандарт требует генерироваться специализации. Потому если программист не написал пользовательскую специализацию, то компилятор сгенерирует свою. Получается специальный полиморфизм на стероидах.

Цитата applegame @ 08.07.15, 13:29

Все, ща D_KEY заявит, что в Rust нет настоящего полиморфизьма!

В случае сырого языка такие выводы делать тяжело. Вопрос в том, является ли это требованием языка, как в C++. Или это бага в реализации.

Цитата

А причина очевидна: В Rust нет виртуальной машины, поэтому он не умеет инстанцировать свои дженерики в run-time как C#.

run-time и инстанцирование тут ни при чем. В Java его нет(по крайней мере раньше не было). В haskell и ocaml нет виртуальной машины, а полиморфные типы есть.

Добавлено 08.07.15, 13:47

Цитата DarkEld3r @ 08.07.15, 13:21

Раст тоже будет бесконечно пытаться выводить типы.

Этого требует спецификация языка? Или это особенность реалиазации? Насколько я понимаю, Rust'у ничего не мешает работать более умно. Это в языке ничего не сломает.

Цитата MyNameIsIgor @ 08.07.15, 13:40

Нет, не один. Ещё раз: Стандарт требует генерироваться специализации. Потому если программист не написал пользовательскую специализацию, то компилятор сгенерирует свою. Получается специальный полиморфизм на стероидах.

Следует ли из этого, что если вдруг в стандарт Хаскеля введут требование генерить специализации (а он по факту во многих случаех их неявно генерит), то Хаскель внезапно перестанет поддерживать ПП?

Цитата D_KEY @ 08.07.15, 13:42

run-time и инстанцирование тут ни при чем. В Java его нет(по крайней мере раньше не было).

Да ну конечно, В жабе автоматическое затирание типов. В плюсах опять же тоже можно сделать затирание, но вручную.

Цитата D_KEY @ 08.07.15, 13:42

В haskell и ocaml нет виртуальной машины, а полиморфные типы есть.

Я точно не знаю как Хаскель и OCaml реализуют рекурсивные специализации, скорее всего затирают тип как жаба.

Цитата applegame @ 08.07.15, 13:49

Следует ли из этого, что если вдруг в стандарт Хаскеля введут требование генерить специализации (а он по факту во многих случаех их неявно генерит), то Хаскель внезапно перестанет поддерживать ПП?

Если он потребует генерировать бинарный код для оптимизации, без изменения системы типов, то не перестанет. Потому отсылки к реализации не к месту.
Если же при этом изменится и система типов по типу плюсовой, то да, перестанет.

Сообщение отредактировано: MyNameIsIgor - 08.07.15, 14:01

Цитата applegame @ 08.07.15, 13:49

Следует ли из этого, что если вдруг в стандарт Хаскеля введут требование генерить специализации (а он по факту во многих случаех их неявно генерит)

Смотря как генерить Можно сломать ПП, а можно не сломать. Ломать свой язык они не станут.

Цитата

В плюсах опять же тоже можно сделать затирание, но вручную.

Потеряв таки типобезопасность. Это не считается

Я в принципе понимаю мысль MyNaneIsIgor. Прописывание в стандарте C++ требований об обязательной специализации ограничивает применимость ПП в C++. Если мы в стандарте C++ разрешим в некоторых случаях не генерить специализации, а выкручиваться другими способами (например затирая тип или даже интерпретируя код шаблона), то это уже будет не современный C++, а например C++20, который по D_KEY наконец-то станет поддерживать ПП.