Rust 1.49

Не понял, и не пытается. Понятно. (Обобщать на всех плюсовиков не буду)

С каких туплов я тебе буду переписывать? Я сколько раз говорил, что вариадиков в плюсовом виде в расте нет. Приходится использовать эквивалентную запись: HList.

Нахрена мне эта коэрсия нужна, если я результат не могу использовать?

Растовские туплы - это не вариадики, аналог вариадиков - HList. Обобщенная конверсия между туплами и HList’ами невозможна. Доволен?

Не понял, и не пытается.

Нет, я отлично понял.

Приходится использовать эквивалентную запись: HList.

Я еще раз говорю, что она не эквивалентна.

Нахрена мне эта коэрсия нужна, если я результат не могу использовать?

Не знаю, зачем вам нужна такая коэрсия. Вы ее сами предложили.

Объясняю, почему данный балабол опять сел в лужу. Идём и смотрим то, что есть на уровне генериков:

fn <impl at src/main.rs:52:1: 57:2>::concat_all(_1: (T, U)) -> <T as Concat<<U as ConcatAll>::Out>>::Out {
    debug self => _1;                    // in scope 0 at src/main.rs:54:19: 54:23
    let mut _0: <T as Concat<<U as ConcatAll>::Out>>::Out; // return place in scope 0 at src/main.rs:54:28: 54:37
    let mut _2: T;                       // in scope 0 at src/main.rs:55:9: 55:15
    let mut _3: <U as ConcatAll>::Out;   // in scope 0 at src/main.rs:55:23: 55:42
    let mut _4: U;                       // in scope 0 at src/main.rs:55:23: 55:29

    bb0: {
        StorageLive(_2);                 // scope 0 at src/main.rs:55:9: 55:15
        _2 = move (_1.0: T);             // scope 0 at src/main.rs:55:9: 55:15
        StorageLive(_3);                 // scope 0 at src/main.rs:55:23: 55:42
        StorageLive(_4);                 // scope 0 at src/main.rs:55:23: 55:29
        _4 = move (_1.1: U);             // scope 0 at src/main.rs:55:23: 55:29
        _3 = <U as ConcatAll>::concat_all(move _4) -> [return: bb1, unwind: bb3]; // scope 0 at src/main.rs:55:23: 55:42
                                         // mir::Constant
                                         // + span: src/main.rs:55:30: 55:40
                                         // + literal: Const { ty: fn(U) -> <U as ConcatAll>::Out {<U as ConcatAll>::concat_all}, val: Value(Scalar(<ZST>)) }
    }

    bb1: {
        StorageDead(_4);                 // scope 0 at src/main.rs:55:41: 55:42
        _0 = <T as Concat<<U as ConcatAll>::Out>>::concat(move _2, move _3) -> bb2; // scope 0 at src/main.rs:55:9: 55:43
                                         // mir::Constant
                                         // + span: src/main.rs:55:16: 55:22
                                         // + literal: Const { ty: fn(T, <U as ConcatAll>::Out) -> <T as Concat<<U as ConcatAll>::Out>>::Out {<T as Concat<<U as ConcatAll>::Out>>::concat}, val: Value(Scalar(<ZST>)) }
    }

    bb2: {
        StorageDead(_3);                 // scope 0 at src/main.rs:55:42: 55:43
        StorageDead(_2);                 // scope 0 at src/main.rs:55:42: 55:43
        return;                          // scope 0 at src/main.rs:56:6: 56:6
    }

    bb3 (cleanup): {
        drop(_2) -> bb4;                 // scope 0 at src/main.rs:55:42: 55:43
    }

    bb4 (cleanup): {
        resume;                          // scope 0 at src/main.rs:54:5: 56:6
    }
}

Есть только эта функция(ну т.е. то, что он наклал руками - там ещё есть потуга для пустого тапла). Очевидно, что подобная функция НЕ может конкатенировать тапл. Она мономорфна.

Т.е. НЕВОЗМОЖНО интерпретировать эту функцию без рантайм-диспатча, либо преобразование её в шаблон с последующий монорфизацией.

Это типичный проблема раст-сектантов. Сектант пытается демонстрацией «работает» доказать выразимость этого в генериках дерьма, но это не выражается. Доказано мною выше.

А работает это дерьмо именно за счёт той модели, которая выражает, т.е. шаблонов.

Не знаю, зачем вам нужна такая коэрсия. Вы ее сами предложили.

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

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

Очевидно, что подобная функция НЕ может конкатенировать тапл. Она мономорфна.

Этот чувак смотрит на код, параметризованный типами T и U, и объявляет, что функция мономорфна. Ну-ну.

Хватить врать

Хватит врать.

возражения есть?

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

Для получения функциональности аналогичной вариадикам, нужно вместо туплов использовать HList’ы.

Вперед, используйте. Вон я выше код функции дал – вызывайте, я посмотрю.

И в этом вся проблема поломоев, именно такие бегут в эту секту.

параметризованный типами T и U

Во-первых T/U не являются типами. Здесь балабол опять сел в лужу. Во-вторых, любая исполняемая функция может быть только мономорфна, статически.

Т.е. если данный балабол сообщает, что функция полиморфна, то полиморфна она может быть только динамически.

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

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

Хватит врать.

Ваше враньё легко продемонстрировать. Приводите ссылку, где я говорил про конверсию туплов в HList’ы, а не о представлении гетерогенных списков в виде HList’ов.

Я вам показал, что нет взаимно однозначного отображения

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

Математика не интересует? Ну смотрите в код.

Вон я выше код функции дал – вызывайте, я посмотрю.

Я дал. Смотрите. Только без очередного плача «Хотю вариадики как в С++».

Ну и я на этом заканчиваю. Кто хотел, тот уже разобрался что к чему.

Во-вторых, любая исполняемая функция может быть только мономорфна, статически.

MIR - это не исполняемый код. Это - «a radically simplified form of Rust that is used for certain flow-sensitive safety checks».

генерики и вся фигня уже отработала.

Мономорфизация производится после генерации MIR.

Ну да т.е. просто наслоение, сначала ллвм/си это внешняя программа чтобы генерировать ассемблер, потом с++/раст/ним это такие замороченные «макросы» для генерации ir, ну и дальше всякий кодоген уровнем выше типа с++ препроцессора, или раста-макросов.

туда руками придется передавать длину списка

Не понял при чём тут это. я имел ввиду такое

impl<A> IntoTuple for (A, ()) {
    type Out = (A, );
    fn into_tuple(self) -> Self::Out {
        (self.0, )
    }
}

impl<A, B> IntoTuple for (A, (B, ())) {
    type Out = (A, B);
    fn into_tuple(self) -> Self::Out {
        (self.0, self.1.0)
    }
}

impl<A, B, C> IntoTuple for (A, (B, (C, ()))) {
    type Out = (A, B, C);
    fn into_tuple(self) -> Self::Out {
        (self.0, self.1.0, self.1.1.0)
    }
}

// и сколько угодно такого нагенерить хоть на питоне

Нет, взаимно однозначного нет. Доказывается тривиально:

((a, b), c) -> (a, b, c)

(a, (b, c)) -> (a, b, c)

Справедливости ради первую строчку никто не обещал. и вторую тоже. Но ни одна из них не подходит под паттерн вложенного списка с терминатором ().

У меня не хватило терпения каждый раз поправлять. Но, похоже человек с математикой не на вы, а на «изыди нечистый». Удачи.

А работает это дерьмо именно за счёт той модели, которая выражает, т.е. шаблонов.

Осталось ввести определенение шаблонов и генериков. Пока у тебя получается от обратного. Работает => шаблоны, не работает => генерики =(

А я вам показал код, который выполняет все функции вашего кода, кроме конверсии из HList в тупл

Клоун, все, что мой код делает – это flatten тупла произвольной глубины. В частности, это приводит твои HList’ы к туплам. Больше ничего. Какой-то там вывод в консоль ничего не значит, это просто проверка. Вы говорите, что я даже не пытаюсь понять – не пытаетесь понять вы, и даже не можете внимательно прочитать текст к коду. Иначе бы вы поняли, что это черновой вариант, и, например, concat там в main вообще не нужен, а можно просто передать готовый «HList».

(и нужна только для удобства).

Хватит врать (x2). Ваши HList’ы ни с чем не совместимы. Она нужна для того, чтобы все не переписывать под них.

Ваше враньё легко продемонстрировать. Приводите ссылку, где я говорил про конверсию туплов в HList’ы, а не о представлении гетерогенных списков в виде HList’ов.

Т.е. вы утверждаете, что HList – не тупл. С головой все в порядке?

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

                    /---(HList)---> (a, b, c)
(a, (b, (c, ()))) <
                    \--- (просто тупл)---> (a, (b, (c, ())))

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

Но, похоже человек с математикой не на вы, а на «изыди нечистый».

Как иронично.

Я дал. Смотрите. Только без очередного плача «Хотю вариадики как в С++».

Клоун, где вызов foo(t: (A, B, C))?

Ну тогда все еще хуже – вы не сможете генерировать только актуальные имплементации, вам придется сгенерировать их какое-то число и надеяться, что этого хватит. Про проблемы, к которым ведет такой подход, я уже писал.

Я имел в виду макрос, который сгенерирует для HList’а указанной длины подходящую сигнатуру. Посмотрите в тот же frunk, там можно писать

let hlist_pat!(f_name, l_name, age, is_admin) = h;

Вот что-то типа такого, но без деструктуринга.

Настолько всё непросто, что они сделали ещё один IR – lccrt.

То есть LLVM под капотом вызывает lccrt, который уже генерирует нативный код. Вроде есть этап ещё с внутренним EIR, но я его только по декомпилу lcc видел и не совсем уверен.

Как-то так работает Clang на данный момент и насколько я знаю проигрывает lcc.

Как-то так работает Clang на данный момент и насколько я знаю проигрывает lcc.

По скорости компиляции или по качеству сгенерированного кода?

(a, (b, (c, ())))

Наконец-то. Правильное представление гетерогенного списка. Поздравляю.

Всё что я хотел, я уже сказал. Можете перечитать.

И на уровне языка у вас способов разграничить их нет

А, извиняюсь. Не всё. Пробуем передать не HList.

|     (a, b, c).concat_all();
|               ^^^^^^^^^^ method not found

вам придется сгенерировать их какое-то число и надеяться, что этого хватит.

Да

Про проблемы, к которым ведет такой подход, я уже писал.

С этим hlist наверное пофиг, вряд ли кому-то надо слишком длинные списки. А в общем случае это и есть недостаток макросов.

Пробуем передать не HList.

Всё что я хотел, я уже сказал. Можете перечитать. «похоже человек с математикой не на вы, а на «изыди нечистый»» (с)

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

Придется делать Construct/TryConstruct или же марать код с Result<T, !> – зато код дублировать не придется.

Когда ! допилят, то вполне себе вариант.

Кстати, я подумал, что, наверное, можно и From/TryFrom использовать. Тогда и новые трейты вводить не придётся.

Читайте еще раз, вы так ничего и не поняли.

Да что тут не понять? HList в виде (a, (b, ())) можно интерпретировать как тупл из двух элементов.

Если программист хочет работать с туплом, но передаёт его в функцию, принимающую HList, то это - ошибка. Как передать long long в функцию, принимающую int, и ожидать, что компилятор догадается о намерениях.

Поэтому HList во frunk’е сделан отдельным типом. Я, для иллюстрации, использовал более компактное в записи представление в виде тупла определённой структуры.

Рассуждения об отсутствии взаимооднозначного соответствия (которое присутствует), сильно помешали понять, что именно не нравится.

Да что тут не понять? HList в виде (a, (b, ())) можно интерпретировать как тупл из двух элементов.

А можно не интерпретировать.

Если программист хочет работать с туплом, но передаёт его в функцию, принимающую HList, то это - ошибка

Вы реализовали HList для тупла. Теперь передача в функцию HList’а и тупла неразличимы от друг друга.

Поэтому HList во frunk’е сделан отдельным типом

Я, для иллюстрации,

Вот с этого вам и стоило начинать. Все ваши проблемы растут именно из вашего внезапного желания написать код на туплах, хотя задекларировать cons и nil потребовало бы нескольких строчек. Мне кажется, я знаю, откуда это растет – из усердия применить знания о «высшей математике» преобразования сигнатур (a, b, c) -> d в a -> b -> c -> d. Ну да ладно, не буду гадать.

Впрочем, прав я или нет, а ровно это вам и придется делать – но ручками, чтобы вызвать заветную `foo(a, b, c) от соответствующего HList. Либо деструктурировать через макро, и руками же обратно собирать в списке аргументов.

И еще дополню.

Смотрите. Только без очередного плача «Хотю вариадики как в С++».

И я их действительно хочу. Хотя бы какие-то. Потому что пока их нет, вы так и будете писать руками деструктуринг, притворяясь, что это вариадики.

Заветную foo(a, b, c)

Это у вас пунктик на вариадиках. Мне не сложно написать tuple!(a, b, c).foo(). Хотя, как я десять раз говорил, с ними было бы проще, что не особо важно - писать tuple!() мне ни разу за 4 года не понадобилось.

Скорее качеству сгенерированного кода.

На скорость никто не замерял. Впрочем lcc -O3 и так довольно долго компилирует. Я не думаю что LLVM будет в этом отличаться, зная как процессор полагается на генерацию.

MIR - это не исполняемый код.

Исполняемый, клоун. Это финальный таргет, который далее идёт в кодогенератор.

Это - «a radically simplified form of Rust that is used for certain flow-sensitive safety checks».

Нет, ты обгадился, опять. Даже перепастить клоун не осилил. На уровне mir уже весь генерик-слой отработал. Т.е. всё, что дальше - уже не имеет никакого отношения к генерикам.

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

Ах да, ты же там блеял про «нетипизированные» - дак вот, он не типизированный. И вот вопрос, как же так получаешься? Что клоун блеет «выражает», а в реальности нет? Генерики продуцируют нетипизированный код, который уже используя C++-way типизируются.

Как же так, клоун? Ты же блеял, что у тебя другой путь? Ты же блеял, что генерики выражают? А чего так?

Нет, у тебя большие проблемы с методичкой. Никакого наслоения нет.

llvm-ir(который си, который С++. Это промежуточное представление созданное для С/С++ и на их базе. Оно упрощено синтаксически, платформазависимо, но во всём остальном - это С/С++). Поэтому в ситуации с С/С++ - это компилятор С/С++. И llvm является компилятором.

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

По поводу потуг про макросы - это неверно. Существует внутренняя кодогенерация и внешняя. К любой программе можно написать внешний кодогенератор. В чём различие я писал выше.

Логика внутренней кодогенерации описана семантикой языка. Внешняя кодогенерация никак не описывается семантикой языка, описывается только её вызов.

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

Нет, у тебя большие проблемы с методичкой.

C++ это внешний кодоген для llvm-ir а gcc это внешний кодоген для асм, почему нет? И то что оно в первую очередь сейчас для С++ и по своему принципу близко к си это вопрос времени, т.е. так может остаться а может и нет. Вон у яблочников уже есть свой форк. Но если тебе методички присылают разрабы и там написано «что нет», то я спорить не буду. То что кодоген с++ кода через с++темплейты это внутренности с++ в отличии от препроцессоров или расто-макросов, я не спорю.

Это финальный таргет, который далее идёт в кодогенератор.

Читай: https://rustc-dev-guide.rust-lang.org/overview.html#intermediate-representations

Например: «Because MIR is still generic, we can do a lot of analyses here more efficiently than after monomorphization.»

С остальными бредовыми идеями обращайся в спортлото.

Генерики продуцируют нетипизированный код, который уже используя C++-way типизируются.

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

15я страница, ну точно значит делаем всё правильно если у реакционных элементов так горит, ощущают опасность. Про Nim и Crystal молчат

Это у вас пунктик на вариадиках.

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

с ними было бы проще, что не особо важно - писать tuple!() мне ни разу за 4 года не понадобилось.

Да нет, вам не понадобилось, потому что вы это нигде и никогда не используете. Я еще раз говорю, я не видел ни одного крейта, который имел бы реальное применение и использовал frunk или реализовывал hlist’ы сам. Почему? Потому что это бесполезно.

После того как всё протайпчекалось информация о типах уже не нужна.

Опять же - херню несёшь.

Остается С++ way (ну такой уровня 03),

Бездарность блеяла, что у него не C++-way.

но уже без ошибок при инстанциировании темплейтов.

Опять же - херню несёшь. Оно там попросту мономорфно. Если бы всё было так - никто ты шаблоны после инстанцирования нечекал.

Давай попроще. Это говно тебя заставляет типизировать код два раза. И именно за счёт этого она не чекается. Т.е. ты попросту не можешь написать такую логику, которая требует чекинга. Но это не значит, что ты ушёл от чекинга - ты просто обмазался дерьмом.

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

У них нет тайпчекера вприцнипе. Чекер уже кончился на уровне до mir, после уже начинаются ассерты. Хотя и сам чекер на 90% состоит из бездарных ассертов, без какой-либо системы.

Оно там попросту мономорфно.

вот так выглядит вызов

_8 = <((i32, (char, (i32, (i32, (i32, (i32, (i32, ()))))))), ((&str, ((), (bool, ()))), (((f64, ()), ()), ()))) as ConcatAll>::concat_all(move _9)

что ты подразумеваешь под мономорфно?

Зачем нужен rust, когда есть D? Это настоящий последователь C/Objective-C/C++.

А что это даёт? Звание «настоящего последователя», в смысле.

Ну и заодно интересно, что у D от Objective-C?

А что это даёт? Звание «настоящего последователя», в смысле.

Это говорит о том, что C - хороший язык, но у него есть недостатки, ибо язык старый. Эти недостатки пытаются исправить в D, не уничтожая язык полностью.

Ну и заодно интересно, что у D от Objective-C?

То же, что и у Objective-C от C.

Да всем без разницы, кроме царя. Какая опасность? Что в расте можно будет также просто создавать гетерогенные деревья как в других, «небезопасных» языках? У раста своя узкая ниша, у других инструментов - своя и пошире будет.

Гетерогенное? Ну можно у напихать трейтов. Если список ограничен - можно enum. Да и вообще, учитывая что гетерогенное дерево это сверх редкая задача - если прямо безумно гетерогенное нужно, я не очень понимаю зачем, то это разумный случай для unsafe.

Вообще смешно «Какая опасность? Что в расте можно…». Было бы можно, то все, коленки бы дрожали? Ну вот можно, я назвал несколько способов.«Какая опасность? Что в С++ можно писать код с высоким уровнем гарантий от комплятора, например о многопоточном доступе». Не думал что Rust - это по многим параметрам расширение ниши по сравнению с С++? Например на нем можно писать и системный код и простую вебню

Готов слушать крики что unsafe не Rust

Речь о том, что Раст просто один из инструментов, заточенный под узкую нишу в ущерб другим. И пример про гетерогенное дерево именно про это. Раст, выигрывая в одном, проигрывает в другом. Это нормально, каждый выбирает подходящий для своих задач инструмент. А вот что ненормально - это хайп вокруг Раста. Но он уже успокаивается. Этот хайп вреден для языка самого, в первую очередь, он привлекает не только потенциальных пользователей, но и много разного мусора, что в итоге идет только во вред.

З.Ы. ах да, гетерогенное дерево это очень даже актуальная задача. Иерархия виджетов в гуях - именно гетерогенное дерево. Разве что гуй для Раста не нужен...

То же, что и у Objective-C от C.

Ну то есть, нет никакого смысла включать Objective-C в список? Или же можно наоборот добавить все языки у которых есть хоть что-то общее с С.

Ну то есть, нет никакого смысла включать Objective-C в список?

Любой код на С является кодом на Objective-C. Objective-C же надмножество С. Ты о чём вообще?

Зоопарк, одним словом. Это один из недостатков C и его подобий.

Гуй - идеальный сценарий чтобы использовать трейты

Я думаю, надо ещё включить Objective-C++ и С– в список.

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

Для иерархии виджетов в гуе нужно чтобы как родительский виджет имел ссылку/указатель на дочерние виджеты, так и чтобы дочерние виджеты имели ссылки/указатели на своих родителей. В угоду борроу чекеру Раст НЕ ПОЗВОЛЯЕТ это сделать без танцев с бубнами, в отличие от «небезопасного» С или С++. Но и этих танцев до сих пор не хватило, чтобы сделать хоть какой-то гуй.

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

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

Ну прямо нужно чтобы были ссылки на друг друга )

Вот Gtk+ например построен на счетчиках ссылок. Ничего, все довольны. Системы счетчиков ссылок - просто рантайм описание владения. Родитель владеет детьми - Rc. Дети не владеют родителем, дети не владеют друг другом из разных ветвей иерархии - std::rc::Weak.

Не совсем понятно почему это все «бубен». Просто декларация правил владения, которое к счастью понятно в данном случае.

Будешь мне сейчас ставить условие что нужно сделать как-то намного лучше чем в Gtk+? Оно уже лучше, не нужно GObject строить