а где сама туева хуча компилируемых языков-то? Vala, D, Rust, Go... из этих вроде Go более-менее популярный... а что-то менее экзотическое есть? так чтобы на нём реально писали.

С++?

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

а то именно так и получается, что из всех компилируемых языков всё равно пишут только на C и C++, и в порядке эксперимента на других...

А чего ты ждал? Что все ломанутся переписывать 30-летнее легаси на Rust и Go просто так, лол?
Ты говорил про крутость си в написании библиотек в плане простоты прикручивания биндингов. Я тебе ответил, что этим преимуществом обладает почти любой из компилируемых языков.
При чем тут кто на чем пишет энтерпрайз?

дык «почти любой из туевой кучи». а где куча-то? если в итоге пишут только на C и C++. куча это когда много популярных...

да и 30-летнее легаси-то ладно. но хоть бы новьё какое-то писали. не мешает же никакое легаси в вебе существовать зоопарку всяких руби и питонов и ещё новым появляться

«почти любой из туевой кучи». а где куча-то?

То есть ты все таки согласен, что биндинги — не уберфича Си?

если в итоге пишут только на C и C++

Кто?

куча это когда много популярных...

Все, что ты перечислил, включая Rust и Go — популярные языки.

но хоть бы новьё какое-то писали

Таки, внезапно, и пишут.
Или ты ожидаешь, что в условиях нехватки специалистов и библиотек на новых языках, все бросятся писать новые проекты на них?

да конечно согласен (хотя... если выбирать из популярных - то хз), правда что в go можно c abi делать, не знал (там прозрачно? а C-шные либы прозрачно можно юзать? без написания биндингов?)

гм. ну крупные/популярные проекты есть на этих языках? на Go видел. на Vala по идее какие-то Gtk'шные проекты должны быть, другое дело что тоже что из этого крупного? на Rust пока только Servo вроде из известного, для него и сделан. а на D? что-то есть вообще?

Ну милчеловек, приехали, в 2016 году надо бы уметь пользоваться гуглом

Собственно, в C++ вы можете определить int f(int) в пространствах имен A и B. Если вы сделаете using namespace A и using namespace B одновременно, то не сможете просто вызвать f(0). Вам придется уточнить имя f.

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

Вот представь (просто пример). Вася реализовал Display для String и теперь, тебе в каждом месте использования типа String как Display (println!("{}", string);) прийдётся указывать, что ты хочешь именно реализацию из std...

И в первом же абзаце то, о чём я говорю.

The alternative to coherence is to have some way for users to identify which impls are in scope at any time. It has its own complications;

Там complications, которых ты не описываешь.

Пользуясь случаем, хочу спросить:
Можно ли сделать конверсии с помощью Into, From и As[Mut]Ref автоматическими, наподобии того как работает Deref?

Предположим, я хочу определить свой MyString, обернутый вокруг обычной строки, чтобы реализовать для него какие-то сторонние трейты и получить желаемое поведение.
Но если я так сделаю, каждый раз при передаче MyString в функцию, придется вызывать into(), а при приеме — from().
Почему нельзя это вынести как сахар и при взятии ссылки разворачивтаь в as_ref(), при передаче автоматически подставлять into() и при биндинге с аннотацией типа вызывать from()

Искал RFC или хоть какие-то намеки, но ничего не нашел

короче чо-то попиливают, но дикой популярностью не пахнет

А теперь самый главный вопрос, какая из реализаций претендует на использование по-умолчанию?

Если обе реализации одновременно введены в область видимости, то никакая.

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

Только если обе одновременно оказались в области видимости.

прийдётся указывать, что ты хочешь именно реализацию из std...

Если я сделал use для Васиного модуля, то да, придется. Если не сделал, то не придется.

Если я сделал use для Васиного модуля, то да, придется. Если не сделал, то не придется.

Речь идёт не о модуле, а о реализации трейта. Если подключать трейты по use mod;, то я считаю это не правильно, т.к. любая реализация трейта может привести к необходимости правки всех мест где возникают конфликты, то есть я написал impl Display for String и поломал все модули которые используют мой модуль. Если ты хочешь использовать String как Display, то откуда компилятору знать, какой Display использовать? С когерентной системой типов такой проблемы нет, ты просто указываешь use Trait;, но с множественной реализацией так не работает, необходимо указать именно конкретную реализацию.

Если обе реализации одновременно введены в область видимости, то никакая.

Только если обе одновременно оказались в области видимости.

То есть реализация по-умолчанию отсутствует и необходимо явное use impl_T_for_S; для каждой реализации? То есть в каждом крейте у нас будет свой prelude, который надо будет подключать в каждом модуле для использования реализаций трейтов для типов крейта.

use a::{S, Clone_for_S, Display_for_S, Debug_for_S, etc};

Перечитайте, пожалуйста, то, что я вам отвечал. Там все описано.

Перечитайте, пожалуйста, то, что я вам отвечал. Там все описано.

Нет, это вы перечитайте всю ветку, а то каждый ответ как лепет глухонемого.

каждый ответ как лепет глухонемого.

А - аргументация.

А - аргументация.

Можно ближе к делу, уже реально достало.

Только если обе одновременно оказались в области видимости.

То есть реализация по-умолчанию отсутствует и необходимо явное use impl_T_for_S; для каждой реализации?

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

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

Как ты будешь вводить реализацию в область видимости?

Как ты будешь вводить реализацию в область видимости?

Это не ответ на мой вопрос. Но попробую еще раз.

Есть тип S. Есть трейт T. Есть модуль Vasya с реализацией T для S. Есть модуль Kolya с другой реализацией T для S.

Если я делаю только use Vasya, то вижу только одну реализацию T для S. Она и используется по умолчанию.

Если я делаю только use Kolya, то вижу только одну реализацию T.

Только если я делаю и use Vasya, и use Kolya, то тогда при попытке задействовать T для S возникает неоднозначность, на которую должен указать компилятор.

Это не ответ на мой вопрос. Но попробую еще раз.

Два чая этому господину.

Только если я делаю и use Vasya, и use Kolya, то тогда при попытке задействовать T для S возникает неоднозначность, на которую должен указать компилятор.

Так это то, о чём я и говорил.

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

Мне продолжить объяснять на сколько это глупый подход?

Мне продолжить объяснять на сколько это глупый подход?

Почему-то вам кажется, что я не понял вашу точку зрения. Однако, я ее давно понял. Просто не считаю ее правильной.

Однако, я ее давно понял.

Однако ранее:

Перечитайте, пожалуйста, то, что я вам отвечал. Там все описано.

----

Просто не считаю ее правильной.

=/

Я тебе говорю, у нас есть проблема, а ты мне, я считаю вашу точку зрения не правильной...

С предложенной тобой моделью, любая, Карл, реализация трейта может поломать код в любом месте.

В общем, где грань проходит? (:

Лучше сделать

#define private public

#include «нечто.h»

И дальше лезь куда хочешь.

Я тебе говорю, у нас есть проблема, а ты мне, я считаю вашу точку зрения не правильной...

Или вам так кажется.

Или вам так кажется.

Опять 25...

Можно ближе к делу, уже реально достало.

До появления более менее вменяемого наследования(хотябы как в go) rust не сможет заменть c++. А какой тогда от него толк? Обменять теоретическую стабильность кода на замедление написания кода? Когда начнут делать rust++?

Опять 25...

Очевидно, что проблема непонята. Мне то же. Сильное ощущение, что вы видите то, что другие увидеть не могут. Как называются такие люди с воображаемыми друзьями вы знаете?

Когда начнут делать rust++?

Когда концепты в С++ появятся, то есть в районе 2025.

Товарищ выше предлагает такую концепцию.

// crate t
trait T {
    fn foo(&self) {}
}

// crate s
struct S {}

// crate a
impl t::T for s::S {}

// crate b
impl t::T for s::S {}

// crate c
use a; // неявное использование реализации T

(S {}).foo();

// crate d
use a; // неявное использование реализации T
use b; // неявное использование реализации T, конфликт
use a::T for s::S; // явное использование T из a

(S {}).foo();

Я ему говорю, что реализация любого трейта может вызвать такой конфликт, что означает явное указание реализации. Если кто-то реализует в crate b trait T for S, это может поломать любой др. код, который использует неявное T for S из др. места.

К примеру. Я реализовал Display для String, это будет означать явное указание use std::fmt::Display (или my::Display) for std::string::String в каждом месте, где используется мой код.

Если кто-то реализует в crate b trait T for S, это может поломать любой др. код

Вот это непонятно. Почему любой, а не только тот который попробует использовать b?

Вот это непонятно. Почему любой, а не только тот который попробует использовать b?

Я это и имею в виду.

Я это и имею в виду.

Похоже ваш друг и в самом деле воображаемый. :)

Что, имхо, превращает эту воображаемую фичу в пшик.

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

Тем не менее, фича всё-таки есть: можно создавать свои трейты и реализовывать их для «чужих» типов или наоборот. И в большинстве случаев этого должно хватать.

Впрочем, доступа к приватным данным всё равно не будет.

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

Вот я тоже не понял, почему аноним говорит про поломку любого кода.

Ну я не спешу. Тестировал на 1.14, если вдруг на 3.21 это станет критическим багом, то можно будет неплохо заработать шантажируя слить в паблик. Годный план, согласен?

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

Ну давай ещё раз. Есть либа с интерфейсом «ползти» и типом «улитка». И в С++ и в расте к приватным данным обратиться будет нельзя. Как по мне, инкапсуляция не нарушается, но идём дальше.

Опять же, в обоих языках можно в другой либе создать интерфейс «летать» и прилепить его к улитке. Тут начинаются различия - в С++ для этого надо делать обёртку («летающая_улитка»), хотя можно обойтись и внешней функцией. И вот тут начинается самое интересное. Посмотрим, что будет в обоих языках при попытке использовать обе либы.

Передать летающую_улитку по базовому интерфейсу в С++ можно, но если та сторона ничего не знает, то ничего не случится. Аналогично в расте - трейт надо импортировать явно. И, как по мне, это ничем не отличается от явного использования функции типа fly(Snail&) в С++. Ну или создания обёртки и использования её методов. Или динамик каста к нужному интерфейсу, раз уж мы о нём знаем.

Вася реализовал Display для String и теперь, тебе в каждом месте использования типа String как Display (println!(«{}», string);) прийдётся указывать, что ты хочешь именно реализацию из std...

Если ты импортировал Васину реализацию, то почему бы и нет? Опять же, можно сделать синтаксис для выбора дефолтной реализации в общем случае и каких-то других для отдельных вызовов.

Мне продолжить объяснять на сколько это глупый подход?

Попробуй объяснить мне.

то есть я написал impl Display for String и поломал все модули которые используют мой модуль.

Почему? Ведь реализации (кроме «дефолтных» из prelude) надо каждый раз явно импортировать. То есть, у тебя будет использоваться своя реализация Display для строк, но у тех, кто использует твою либу, если они явно не захотели твою реализацию, будет использоваться дефолтная.

Или в чём проблема?

И дальше лезь куда хочешь.

Справедливости ради, это UB (в общем случае).

Годный план, согласен?

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

Да тут же только нищеброды тусуются. Думаешь через пару лет типичный rust'овщик таки начнет хоть сколь-нибудь зарабатывать?

Если ты импортировал Васину реализацию, то почему бы и нет? Опять же, можно сделать синтаксис для выбора дефолтной реализации в общем случае и каких-то других для отдельных вызовов.

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

Почему? Ведь реализации (кроме «дефолтных» из prelude) надо каждый раз явно импортировать. То есть, у тебя будет использоваться своя реализация Display для строк, но у тех, кто использует твою либу, если они явно не захотели твою реализацию, будет использоваться дефолтная.

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

а не импорте реализации (как я предлагал выше).

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

Руки надо бы иметь из плеч, а не из жопы.

Зачем у тебя main в lib.rs ?

https://rurust.github.io/rust_book_ru/src/crates-and-modules.html

«Так как в этом контейнере нет функции main(), и называется он lib.rs, Cargo соберет этот контейнер в виде библиотеки.»

Cargo считает lib.rs за корень контейнера.

Твои проблемы, это не проблемы rustc или даже cargo. Это твои личные проблемы. А ты, жадный школьник, ещё и бабки хочешь заработать на своих кривых ручках. Сходи на reddit и посмеши народ в /r/rust

Митап по Rust в Kaspersky Lab

Уважаемые участники форума, каждый месяц мы в «Лаборатории Касперского» проводим встречи CoLaboratory, на которых технические специалисты с различными интересами могут встретиться и поговорить с экспертами. Встреча 22 ноября будет посвящена Rust — приходите! https://events.kaspersky.com/event/rust2