LINUX.ORG.RU

Как жить без специализации impl-ов?

 


0

6
enum Edge<T> {
	Edge(Option<T>),
	Nothing
}

impl<T> fmt::Display for Edge<T> {
	fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
		write!(f, "{}", match self {
			&Edge::Edge(_)        => "E",
			&Edge::Nothing        => "-",
		})
	}
}

impl<T: fmt::Display> fmt::Display for Edge<T> {
	fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
		write!(f, "{}({})", match self {
			&Edge::Edge(_)        => "E",
			&Edge::VirtualEdge(_) => "e",
			&Edge::Nothing        => "-",
		}, match self {
			&Edge::Edge(Some(v))        => v,
			&Edge::VirtualEdge(Some(v)) => v,
			_                           => "-"
		})
	}
}

Так нельзя, потому что в расте нет специализации. А как в таких случаях надо писать?

Замысел состоит в том, что второй impl основной, а первый — fallback на тот случай, если Edge инстанцировали от чего-то, что нельзя распечатать.

★★★★★

Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от anonymous

возможности для замены которого есть в Расте и нынче вводятся даже в кресты.

Насчёт крестов интересны подробности - о чём ты? Пока что вижу обратное. Скажем, хватает запросов на добавление возможности параметризировать константами и соответствующие «ишью» не закрыты.

Относятся, ибо возникли от неправильного её использования.

Хотел спорить, но вообще вопрос «филосовский». Как по мне, проблема (если она вообще есть) не в специализации, а в изначальном желании. Раст, конечно, старается не способствовать стрельбе по ногам, но часто предоставляет возможности сделать «по своему». Не будь специализации, автор мог бы через макросы что-то наворотить и не факт, что было бы лучше.

А я могу не посмотреть срок годности молока и отравиться, так что мыть яблоки не нужно. Намёк ясен?

Нет. Вообще мне это напоминает разговоры про unsafe и аргументы типа «раз unsafe есть, то значит у нас нет безопасности вообще».

Тогда тебе специализация и нафиг не сдалась.

Это ещё почему? По твоему, оптимизации для отдельных типов не могут потребоваться в рамках одного проекта?

Или, по-твоему, мыть руки после туалета - тоже догматизм?

Иногда, да. Скажем, раз уж ты любишь странные аналогии: если у нас из крана кислота течёт, то лучше не помыть, чем слепо следовать правилам.

Вангану - он тупо сам до конца не понимает, зачем нужна специализация, вот и выкатил такой идиотский пример.

Скорее натягивает плюсовые привычки на новый язык.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Насчёт крестов интересны подробности - о чём ты?

constexpr

Скажем, хватает запросов на добавление возможности параметризировать константами

Ты о чём? В крестах это давно есть.

проблема не в специализации, а в изначальном желании

Именно. Но это никак не противоречит моим словам.

Вообще мне это напоминает разговоры про unsafe и аргументы типа «раз unsafe есть, то значит у нас нет безопасности вообще».

Зря. Я говорю, что специализация есть, но не стоит использовать её направо и налево. Как и unsafe.

если у нас из крана кислота течёт

Я не зря раньше писал тебе про TMP. Связь с твоей аналогией понятна?

Скорее натягивает плюсовые привычки на новый язык.

Нет. Даже у трупастрауса написано, что такое специализация, для чего её использовать, а для чего - не стоит.

anonymous
()
Ответ на: комментарий от DarkEld3r

По твоему, оптимизации для отдельных типов не могут потребоваться в рамках одного проекта?

Могут в экзотических случаях. В 99% случаев библиотечных типов хватает, либо те оптимизации того не стоят.

Правда я предпочитать расширять это требование до «ожидаемое поведение»

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

anonymous
()
Ответ на: комментарий от intelfx

где этот тип используется в структуре данных

Да плевать. При расширении функционала старый код должен работать так, как работал. Open/close principle зачем придумали?

anonymous
()
Ответ на: комментарий от anonymous

constexpr

Погоди, ты говорил про «костыльный шлак», для которого в расте якобы замена есть и которая вводится в плюсы. Вот только constexpr появился раньше (стабильного) раста. Причём в последнем вычисления на этапе компиляции делаются не так просто (хотя и позволяют много больше) и до сих пор являются нестабильной частью языка.

Ты о чём? В крестах это давно есть.

Ага, а в расте нет. Собственно, спорил с «направлением развития». По некоторым параметрам наоборот раст догонят. А по другим в плюсах, к сожалению, и не собираются ничего делать.

Связь с твоей аналогией понятна?

Не совсем.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Причём в последнем вычисления на этапе компиляции делаются не так просто (хотя и позволяют много больше) и до сих пор являются нестабильной частью языка.

Ну значит, с растом я ошибся. Впрочем, это не отменяет того, что в крестах compile-time вычисления переводят на нормальное CTFE вместо костылей на TMP.

Не совсем.

А она в том, что TMP, как и кислота в кране - это крайний случай. Если такая ситуация возникла, то у тебя уже проблемы посерьёзней неправильного использования специализации/немытых рук.

anonymous
()
Ответ на: комментарий от DarkEld3r

предпочту удобный способ неудобному, но «более правильному»

Правила иногда приходится нарушать, безусловно. Но ящитаю, что, чтобы нарушать правила, нужна более веская причина, чем «мне так удобнее». Даже если это лишь правила хорошего тона.

anonymous
()
Ответ на: комментарий от anonymous

Если такая ситуация возникла, то у тебя уже проблемы посерьёзней неправильного использования специализации/немытых рук.

Хочется поспорить. Конечно, метапрограммирование на шаблонах - то ещё удовольствие, но за неимением лучшего... Опять же, не уверен, что всегда можно найти решение лучше.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Хочется поспорить.

И опять ради спора?

но за неимением лучшего

Я и не говорил, что есть лучше. Я говорил лишь, что

метапрограммирование на шаблонах - то ещё удовольствие

Опять же, не уверен, что всегда можно найти решение лучше.

Если умело использовать кодогенерацию, нужда в TMP останется только в библиотеках, которые пытаются сделать из крестов нормальный ЯП типа буста. Довольно узкая ниша, в общем-то.

anonymous
()
Ответ на: комментарий от anonymous

И опять ради спора?

Похоже на то... поэтому продолжать не буду.

DarkEld3r ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.