LINUX.ORG.RU

Rust 1.26

 


5

11

Команда разработчиков языка Rust рада представить новую версию Rust 1.26.0. Rust — системный язык программирования, ориентированный на безопасность, скорость и параллельность.

Обновить Rust можно с помощью команды:

curl https://sh.rustup.rs -sSf | sh # если у вас еще не установлен rustup
rustup update stable

Основные изменения:

  • Вторая редакция книги «The Rust Programming Language» (почти) готова, и теперь рекомендована по умолчанию для ознакомления вместо первой версии. Также готовится к выходу бумажное издание книги.
  • impl Trait в заголовках функций

    Стало возможно указывать Trait в заголовке функции в качестве типа возвращаемого значения:

    fn foo() -> impl Iterator<Item = i32> {
        // ...
    }
    
    Это позволяет не указывать полный тип в заголовке функции, если с точки зрения API конкретный тип не имеет значения. Такой синтаксис подразумевает статическую диспетчеризацию, в отличие от Box<Trait>.

    Также эта возможность удобна для использования с замыканиями (closures):

    fn foo() -> impl Fn(i32) -> i32 {
        |x| x + 1
    }
    

    Новый синтаксис теперь можно использовать и для типов аргументов фунции:

    // раньше нужно было писать так:
    fn foo<T: Trait>(x: T) {
    
    // сейчас можно так:
    fn foo(x: impl Trait) {
    

  • Неявное разыменование ссылок в сопоставлении с образцом (match, if let, ...)

    Теперь следующий код больше не вызывает ошибку компиляции:

    fn hello(arg: &Option<String>) {
        match arg {
            Some(name) => println!("Hello {}!", name),
            None => println!("I don't know who you are."),
        }
    }
    
    и эквивалентен такому:
    fn hello(arg: &Option<String>) {
        match arg {
            &Some(ref name) => println!("Hello {}!", name),
            &None => println!("I don't know who you are."),
        }
    }
    
    То же работает и для &mut + ref mut.

  • Раскрытие срезов (slice) в сопоставлении с образцом
    fn foo(s: &[u8]) {
        match s {
            [a, b] => (),
            [1, _, _] => (),
            _ => (),
        }
    }
    
  • Закрытые интервалы вида 0..=4, включающие обе границы в диапазон перечисления
        for i in 0..=4 {
            println!("i: {}", i); // выведет 0, 1, 2, 3 и 4
        }
    
  • Новые целочисленные типы i128 и u128
  • Функция main() теперь может возвращать тип Result
    use std::fs::File;
    
    fn main() -> Result<(), std::io::Error> {
        let f = File::open("bar.txt")?;
    
        Ok(())
    }
    
  • Ускорения в работе компилятора
  • Стабилизирована функция std::fs::read_to_string
  • При форматировании через trait Debug теперь можно выводить целочисленные значения в шестнадцатеричном виде:
    assert!(format!("{:02x?}", b"Foo\0") == "[46, 6f, 6f, 00]")
    
  • Номер версии Cargo, начиная с этого релиза, изменяется синхронно с номером версии Rust

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: tailgunner (всего исправлений: 22)

Ответ на: комментарий от tailgunner

Если речь идет о том, означают ли два упоминания имени std::fmt::Debug разные symbols - нет, это один и тот же трейт. Он реализуется типами обеих значений, которые автор my_val пытается вернуть из функции, но это разные типы, а возврат из такой функции значений разных типов запрещен правилами языка. Поскольку из-за impl Debug в my_int и my_str оба типа анонимизированные (anonymized), их имена не печатаются.

Хорошо, не будем вдаваться в подробности. Пусть будет один трейт, но разные типы. Таким образом, мы имеем в диагностическом выводе компилятора информацию о двух РАЗНЫХ типах. При этом с точки зрения человека информация о них ОДИНАКОВАЯ с точностью до символа. Замечу, что диагностический вывод компилятора предназначен именно для человека. Согласны со мной?

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

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

Да.

Хорошо. А почему вы тогда категорично (обращаю на это внимание) утверждаете что:

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

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

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

Хорошо, не будем вдаваться в подробности.

Будем.

Таким образом, мы имеем в диагностическом выводе компилятора информацию о двух РАЗНЫХ типах.

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

При этом с точки зрения человека информация о них ОДИНАКОВАЯ с точностью до символа.

Да. Но мне интересно, какой вывод лично ты считал бы полезным.

Замечу, что диагностический вывод компилятора предназначен именно для человека. Согласны со мной?

Я согласен, что вывод предназначен для человека. Жаль только, что под рукой нет rustc и я не могу запустить rustc --explain E0308, как советует компилятор.

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

Вы еще скажите, что конструктивная критика, высказанная в подобных топиках на LOR-е, как-то повлияет на развитие языка.

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

Хорошо, не будем вдаваться в подробности.

Будем.

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

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

Таким образом, главная полезная информация в этом сообщении - что компилятор обнаружил разные типы там, где ожидал одинаковые.
Я согласен, что вывод предназначен для человека. Жаль только, что под рукой нет rustc и я не могу запустить rustc --explain E0308, как советует компилятор.

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

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

Да. Но мне интересно, какой вывод лично ты считал бы полезным.

Я бы предпочел, чтобы в выводе не было написано что ожидается тип 'Type1', а получен тип 'Type1'. Это реально разрыв шаблона. Лучше просто написать, что-то вроде тип параметра не соответствут типу аргумента, а дальше ссылка на детали. Ну и типы же компилятор выводит, так что в идеале fully qualified type name напечатать можно. Чтобы бы было видно что это разные типы. Тогда понятно все станет без E0308.

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

Хорошо, не будем вдаваться в подробности.

Будем.

Но мы же уйдем тогда в демагогию?

Вот как раз без подробностей мы и уйдем в демагогию.

Моя мысль проста - сообщение компилятора в том виде недостаточно информативно

Сообщение доносит до пользователя суть - разные типы там, где требовались одинаковые. И ты пока не ответил - какой информации тебе не хватает?

И я встречал такие диагностические сообщения в другом языке и надо сказать я немало удивлен вашей безапелляционностью

Какие «такие» - недостаточно информативные по твоему мнению? И сразу оказывался в «а...е» и «ступоре»? Если что, именно в этом разница между «могли бы и получше сделать» и «outrage».

Когда я встретил первый раз такое сообщение я потратил уйму времени на решение в общем-то простой проблемы

Какое «такое» - про два anonymized типа? У тебя есть большая кодовая база на Rust и в ней уже есть impl Trait? Потому что в противном случае это не «такое сообщение».

ошибка сбивает с толку

Она ни с чего не сбивает.

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

Я бы предпочел, чтобы в выводе не было написано что ожидается тип 'Type1', а получен тип 'Type1'

Но он именно так и ожидался. Таков код.

Лучше просто написать, что-то вроде тип параметра не соответствут типу аргумента

expected anonymized type, found a different anonymized type

Ну и типы же компилятор выводит, так что в идеале fully qualified type name напечатать можно

Напиши, что бы ты хотел видеть.

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

Вот как раз без подробностей мы и уйдем в демагогию.

Да мы уже ушли. Именно из-за ненужных деталей.

ошибка сбивает с толку

Она ни с чего не сбивает.

Ну как она не сбивает? Когда два разных типа в сообщении напечатаны одинаково символ в символ? В чем разница между

`impl std::fmt::Debug`
и
`impl std::fmt::Debug`
можете мне сказать? Лично я - не вижу никакой разницы. А вы?

Просто убрать эту строчку и уже было бы лучше. Она не несет никакой информации для программиста и более того, сбивает с толку.

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

Просто убрать эту строчку и уже было бы лучше.

От убирания строки информативность сообщения повысится?

Она не несет никакой информации для программиста

Это две строки. А информация для программиста заключается в двухкратном упоминании anonymized type.

сбивает с толку

Как она может сбивать с толку, когда она совершенно корректна? А если читать строку полностью, она еще и полезна.

Есть здесь у кого-нибудь свежий rustc? Что выдает rustc --explain E0308?

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

Мы ждали человека, который просил не называть его имени, а пришел человек, который просил не называть его имени.

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

От убирания строки информативность сообщения повысится?

Конечно. Потому что остальную информацию в сообщении о разнице типов и про E0308 он же увидит. А с этой строчкой он будет сидеть и думать - как два одинаковых типа могут быть разными? Мозг старается выделить главное - и главным здесь будет не то, что типы разные. А то что типы разные и при этом одинаковые. И без этих двух строчек будет меньше вопросов.

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

anonymous
()
Ответ на: комментарий от tailgunner
$rustc --explain E0308

This error occurs when the compiler was unable to infer the concrete type of a
variable. It can occur for several cases, the most common of which is a
mismatch in the expected type that the compiler inferred for a variable's
initializing expression, and the actual type explicitly assigned to the
variable.

For example:

```
let x: i32 = "I am not a number!";
//     ~~~   ~~~~~~~~~~~~~~~~~~~~
//      |             |
//      |    initializing expression;
//      |    compiler infers type `&str`
//      |
//    type `i32` assigned to variable `x`
anonymous
()
Ответ на: комментарий от red75prim

Мы ждали человека, который просил не называть его имени, а пришел человек, который просил не называть его имени.

Верно подмечено) Я подвис))

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

А, ну и вот это E0308 тоже не особо информативное как я посмотрю. Но я уж промолчу.

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

Вряд ли это можно назвать кортежем. У этого есть длина, определены head, tail, map (как для списка), можно добавить элемент. можно определить свётрку.

можно у кортежа сделать head? tail? как определить свёртку для кортежа?

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

А с этой строчкой он будет сидеть и думать - как два одинаковых типа могут быть разными?

Он не знает, что Debug - это трейт, не видит дважды упомянутый anonymized type, не читал основное сообщение об ошибке, которое говорит «найдены разные типы», и не увидел предложения запустить rustc --explain. Ну да, тогда он будет сидеть и думать.

Всем очевиден факт, что сообщение сбивает с толку, несмотря на свою полную корректность

Как раз утверждение «всем очевиден факт» - это демагогия.

Но вы принципиально не хотите признать тот факт, что вывод компилятора можно и нужно улучшить.

Я принципиально не хочу признавать утверждение, что сообщение недостаточно информативно (и тем более вводит в ступор). Улучшить его, наверное, можно - я уже несколько раз спросил, как

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

Вряд ли это можно назвать кортежем.

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

можно у кортежа сделать head? tail?

Да. Насколько я могу судить, пример на Rust - именно кортеж.

как определить свёртку для кортежа?

Я затрудняюсь определить свертку для элементов разного типа (не имеющих одного супертипа).

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

Он не знает, что Debug - это трейт, не видит дважды упомянутый anonymized type, не читал основное сообщение об ошибке, которое говорит «найдены разные типы», и не увидел предложения запустить rustc --explain. Ну да, тогда он будет сидеть и думать.

Представляешь, он знает, что Debug — это трейт, видит дважды упомянутые Debug и anonymized type, читает сообщение об ошибке, в котором написано, что найдены разные типы. Но, блин, из печати вида:

= note: expected type `impl std::fmt::Debug` (anonymized type)
           found type `impl std::fmt::Debug` (anonymized type)
нифига не понятно, чем же эти «разные типы» отличаются.

Именно это и ставит в тупик.

И именно это тебе и пытаются донести. Но ведь ты же Rust не используешь, какая тебе разница, что там пишет компилятор ;)

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

да, действительно, спасибо за пример.

// к чему бы ещё придраться... ))

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

В хаскеле работает, я писал в качестве упражнения aeson-инстанс для такого списка, всё вроде хорошо. Но лично я не использвоал в коде (да и на хаскеле я пока почти ничего не писал, откровенно говоря).

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

Не получится, negative trait bounds в языке нет, и возможно не будет.

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

нифига не понятно, чем же эти «разные типы» отличаются.

А зачем тебе это знать? Достаточно знать, что они разные, и об этом сказано в сообщении об ошибке:

22 |         return my_str();
   |                ^^^^^^^^ expected anonymized type, found a different anonymized type

Уточнение про «expected ... found» в данном случае не очень полезно, потому что так уж написан код. Можно на Яве сделать классы Kласс и Класс, и потом жаловаться на непонятные сообщения.

Но ведь ты же Rust не используешь, какая тебе разница, что там пишет компилятор ;)

Это знание делает меня счастливее, очевидно же!

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

А зачем тебе это знать?

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

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

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

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

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

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

tailgunner ★★★★★
()

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

Вы лучше вспомните про тридцатиэтажные ругательства компилятора gcc, если что не так с template. Иногда я _специально_ пропускал код через clang, чтобы понять, что же мне хотел донести gcc

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

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

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

Вообще интересно было бы поглядеть на функцию «добавить эл-т в кортеж». Даёшь например на входе (True, 'a', «Hello»), делать add 1, и получаешь (1, True, 'a', «Hello»).

Т.е. мне кажется вряд ли получится для кортежа любой длины это сделать. А для конструкции выше - вполне себе.

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

Что до свётрки - насчёт типов верное замечание. Но если взять такую вот конструкцию и наполнить наполнить её эл-тами одного типа, для которых можно определить свётку, то можно сделать свётрку.

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

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

Нет. Мы хотим, чтобы вторая часть сообщения компилятора помогала понять первую часть. Ну или хотя бы не мешала.

Скажи, какое сообщение ты хотел бы видеть?

Либо без имен типов (т.е. без note с expected и found). Либо же что-то вроде:

   = note: expected type `impl std::fmt::Debug` (anonymized type, i32)
              found type `impl std::fmt::Debug` (anonymized type, String)

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

Ну как бы длина как число явно не выражена в типе

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

Но если взять такую вот конструкцию и наполнить наполнить её эл-тами одного типа, для которых можно определить свётку, то можно сделать свётрку.

Можно написать функцию, которая будет сворачивать такой «список» любой длины, но при этом не параметризована типом списка?

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

критиков Раста идиотами

Критиками они бы были, если бы сначала погуглили по своим вопросам и нашли бы реальный повод для этого. А когда один и тот же идиотский словесный понос в каждой теме о Rust льют это уже не в какие ворота.

Вы чего такие нетерпимые?

Да пока распишешь всё 100500 д*лбаёбам, уже хочется убивать

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

Тут за 11 страниц вообще не было ни слова критики - одни вбросы.

Кажется, за всю историю ЛОРа были только вбросы про раст.

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

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

да, это верно.

Можно написать функцию, которая будет сворачивать такой «список» любой длины, но при этом не параметризована типом списка?

Гм, ну как не параметризована типом... в некотором смысле конечно параметризована. Ну то есть, чтобы быть конкретным, длину вычислять вероятно нужно как то так (псевдокод навскидку, вечером постараюсь набросать реальный пример , и посмотрю что со свёрткой)

class Len a where
  len :: a -> Int

instance Len HNil where
  len HNil = 0

instance Len (HList as) => Len (HList (a ': as)) where
  len (_ ::: rest) = 1 + len rest
т.е. получается некоторая рекурсия по типу. Но вот так определена функция len и ты можешь её использовать для любого такого «списка». Т.е. дополнительных определений не нужно (в т.ч. не нужно объявлять инстансов). Примерно то же будет и со свёрткой если (у меня) не возникнет дополнительных трудностей с ограничениями для типа на свёртку.

ОБН. Т.е. чтобы вычислить длину любого такого списка, нужно создать список и вызвать к нему len, например

xs1 = True ::: 'a' ::: "Hello" ::: HNil
xs2 = (1 :: Int) ::: (1.2 :: Float) ::: ('a', True) ::: False ::: HNil

len xs1 // вернёт 3
len xs2 // вернёт 4
 
AndreyKl ★★★★★
()
Последнее исправление: AndreyKl (всего исправлений: 5)
Ответ на: комментарий от eao197

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

Вот смотрите, в первой части сообщения вы видите, что типы разные. Все верно. Но при этом приведен только один тип, второй неясен. А если там не два типа? Во второй части написано, что типы разные, но названы они одинаково - это корректно по своей сути, но сбивает с толку однозначно, потому что выше написано что они разные. Что касается кода, то когда вы его отправили на компиляцию, это означает, что вы уже считаете что он правильный и ошибки вы там уже не увидели. Т.о. ни чтение первой части сообщения, ни чтение кода по сути ничего дополнительно не дают. Диагностика Е0308 тоже по факту ничего в данном случае не дает - и так уже ясно что типы не совпадают.

= note: expected type `impl std::fmt::Debug` (anonymized type, i32)
           found type `impl std::fmt::Debug` (anonymized type, String)

Вот это сообщение уже снимает все вопросы которые у меня были.

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

Критиками они бы были, если бы сначала погуглили по своим вопросам и нашли бы реальный повод для этого. А когда один и тот же идиотский словесный понос в каждой теме о Rust льют это уже не в какие ворота.

Да пока распишешь всё 100500 д*лбаёбам, уже хочется убивать

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

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

Либо без имен типов (т.е. без note с expected и found).

Уверен, что так будет информативней?

Либо же что-то вроде:

Тогда в таком коде

fn main() {
    fn fn1() -> impl std::fmt::Debug { 1 }
    fn fn2() -> impl std::fmt::Debug { 1 }
    let mut a = fn1();
    a = fn2();
}

Ошибка будет:

  = note: expected type `impl std::fmt::Debug` (anonymized type, i32)
             found type `impl std::fmt::Debug` (anonymized type, i32)

Просто офигеть как стало понятно, блин.

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

Уверен, что так будет информативней?

С какого-то хера здесь регулярно путают «понятность» и «информативность». Информативное сообщение вполне может быть непонятным (как в обсуждаемом случае), а не информативное — понятным.

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

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

Просто офигеть как стало понятно, блин.

Хуже точно не стало.

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

у Rust-а полно каких-то альтернативно одаренных последователей

Еще эти последователи плодят байдинги через unsafe к сишным функциям, даже когда сишная либа реализует стандартный протокол не привязанный к кокнкретному языку.

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

Просто офигеть как стало понятно, блин.

Ну так вот видите, вы нашли еще один момент и если его тоже устранить - компилятор Раста станет еще лучше. А если отрицать все, то компилятор лучше не станет.

Именно про это выше говорил eao197, что нужно конструктивную критику воспринимать и учитывая ее улучшать язык. А не вступать в ряды «отрицалова».

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

С какого-то хера здесь регулярно путают «понятность» и «информативность».

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

Хуже точно не стало.

Стало. Раньше в нём была неочевидным образом описана реальная ситуация, а в твоём варианте там прямая деза. Ибо «anonymized type» - это не «i32».

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

Именно про это выше говорил eao197, что нужно конструктивную критику воспринимать и учитывая ее улучшать язык

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

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

что сами по себе они никому не нужны и никому не интересны

Не интересна «понятность» и «информативность». Ну, ОК.

и именно её я подразумевал под «информативностью»

См.выше про альтернативную одаренность.

а в твоём варианте там прямая деза.

Где? Или мы опять смотрим про альтернативную одаренность?

Ибо «anonymized type» - это не «i32».

Вообще-то там одно другим не заменяется, а дополняется. И i32 следует воспринимать не как замену anonymized type, а как уточнение — из чего же, собственно, и был сделан анонимный тип.

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

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

Не совсем так. Он предложил как сделать лучше в конкретной ситуации. И в ней действительно его решение снимает все вопросы. Затем вы показали ситуацию, где его решение уже не помогает. И это нормально. Значит можно и нужно найти еще лучше вариант. Но из этого не следует, что предложенный им вариант не подходит. Тот кейс, который мы рассматривали с tailgunner'ом его вариант решает на 100%.

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

anonymous
()

Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как спорят о rust.

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

А не разу не сталкивались на практике с такой ошибкой?

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

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

Нередко вижу как в питоне и js пишут типы в комментариях перед функцией

это называется docstring

Нет. Во-первых, в джаваскрипте нет докстрингов. Во-вторых, он описал не докстринги.

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

Не интересна «понятность» и «информативность». Ну, ОК.
См.выше про альтернативную одаренность.

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

как уточнение — из чего же, собственно, и был сделан анонимный тип

Из чего я должен понять, что это уточнение того, из чего сделан тип, а не уточнение самого типа?

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

можешь пояснить, как у тебя получается, что непонятное сообщение может содержать информацию или, тем более, хорошо информировать

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

Номер раз:

error[E0308]: mismatched types
  --> src/main.rs:22:16
   |
22 |         return my_str();
   |                ^^^^^^^^ expected anonymized type, found a different anonymized type

И номер два:

error[E0308]: mismatched types
  --> src/main.rs:22:16
   |
22 |         return my_str();
   |                ^^^^^^^^ expected anonymized type, found a different anonymized type
   |
   = note: expected type `impl std::fmt::Debug` (anonymized type)
              found type `impl std::fmt::Debug` (anonymized type)

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

Из чего я должен понять, что это уточнение того, из чего сделан тип, а не уточнение самого типа?

Видимо, я недостаточно хорошо знаю Rust, чтобы уловить тонкую разницу между «уточнение того, из чего сделал тип» и «уточнение самого типа». Внутри функции, результат которой указан как impl Trait возвращается же какой-то конкретный тип, из которого затем компилятор Rust-а делает анонимный тип. Вот в сообщении компилятора было бы полезно этот самый конкретный тип и увидеть в дополнение к anonymized type.

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

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

Опрос так же показал, что Rust хотят выучить 8.3% респондентов, а Python 25.1%.

При этом об использовании Rust вообще и в профессиональной деятельности в частности данных нет, а Python юзают 38,8% респондентов.

Такой вот «любимый» язычок, ЛОЛ.

З.Ы.:Еще один забавный момент - градус ненависти к Си (62.6%).

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