Релиз языка программирования Rust 1.39

Потому что спецификация T относится именно к имплементации, а не к BTree.

Спасибо, кэп.

impl<A, B, C> задаёт входящие параметры-типы и их ограничения в одном месте. Как в С переменные определяются только в начале функции.

Что должно значить impl Trait<T: Ord> for BTree<T: Eq>?

Можно наверно от этого явного объявления типов избавиться, но пока никто не занялся.

Но для функции спецификацию T мы же можем указать как fn some_func<T>(x: T) -> T where T: Ord + Eq {

impl<A, B, C> задаёт входящие параметры-типы и их ограничения в одном месте.

Но у функций может быть по другому. Через тот же `where`, что как по мне более приятней.

В impl тоже можно where написать.

impl<T> Foo<T>
where T: Clone
{
    fn bar(&self) {}
}

Имплементация структуры и сама структура по идее - разные вещи. Я сталкивался с этим. Тут будет U, например, а там - T. И это разные штуки.

Еще такая хрень будет у тебя когда-нибудь impl<'a, T: 'a> AAA<'a> for BBB<T>

А некоторые хотят implement Write for Foo { public function bar(&self) -> boolean {} }. Вкусы у всех разные.

Ну это же просто неправда! Ocaml не сложнее питона или go какого-нибудь.

Вы на Окамле писали? Я писал. Гораздо сложнее Питона и сложнее Го однозначно. Именно в смысле логики построения кода. Это только в примерах у них на сайте всё кажется просто. А в действительности, если пишем что-нибудь серьёзное, чтобы всё сидело во сложенных функциях, вы производные типы данных и операторы над ними вводить и согласовывать ошизеете.

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

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

А некоторые хотят implement Write for Foo { public function bar(&self) -> boolean {} }. Вкусы у всех разные.

Дело не во вкусах, дело в количестве сущностей, которые ты выписываешь и используешь. Какие там будут кейворды дело десятое. К примеру в Option<Box<Node<’a>>> сразу четыре сущности, а в Node? - всего две. Тут

 impl<’a> Node<’a> { 
     pub fn insert(&mut self, new_val: &’a str) { 

Их 13 (плюс-минус), а тут:

 public func insert(new_val: String) 

Их 5. Проще код - проще писать, проще читать и переваривать, меньше ошибок, большая продуктивность.

И так тихо и незаметно подменил str на String. Тогда сразу писать на жабе остается!

И так тихо и незаметно подменил str на String.

Это аналог на Swift, который почти Rust с человеческим лицом, но у Swift своя беда в виде совместимости с уже существующей инфраструктурой macOS, что здорово изуродовало язык.

Тогда сразу писать на жабе остается!

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

Что такое Node?? Владеющий nullable указатель на Node, аллоцированный дефолтным аллокатором? Те же пять сущностей.

Или больше? Swift кажется ещё ARC добавляет?

Ничего, что в примере на Rust хранится ссылка на строку, а не строка?

Т.е. одну и ту же вещь двумя разными путями описываем, впрчем как и у функции.
КМК это не очень хорошо.
Стоило бы оставить только один вариант.

как в каком-нибудь Swift

Только Swift медленнее. За удобство приходится платить.

Для коротких типов - проще через :, для сложных - проще через where. Всё для людей.

Что такое Node?? Владеющий nullable указатель на Node, аллоцированный дефолтным аллокатором? Те же пять сущностей.

Node? это сахар к Optional. А место хранения уже зависит от типа объекта. Для экземпляров классов используется ARC. Но дело не в этом, если копнуть глубже (что для Rust ты не сделал), то и там сущностей прибавится. Для этого и нужны абстракции, чтоб детали реализации можно было просто помнить (и то не обязательно, если ты новичок).

Только Swift медленнее. За удобство приходится платить.

Да, в основном за счет совместимости с ObjC. Apple не ставила за цель сделать идеальный язык, им надо было иметь совместимость с legacy.

Ну сделай алиас Option<Box<T>> = OptBox<T>

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

Ну сделай алиас Option = OptBox

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

Чтобы ты бесился, это же на поверхности.

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

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

Ничего, что в примере на Rust хранится ссылка на строку, а не строка?

В С++ тоже можно взять string_view, или использовать rvalue reference, не думал, что это принципиально.

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

Начинающий сишник - это особый вид людей, со встроенным пониманием указателей?

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

Я в общем о том-же. Скомпилировал, запустил, упало, шишка. Приходится разбираться. Впрочем с unsafe кодом примерно такая-же история.

И что, Ада тоже мертвая?

а fortran мертвый?

ну в контексте популярности rust&go относительно d

В С++ тоже можно взять string_view

(since C++17)

Ну возьми.

У нас тут есть начинающие сишники на лоре - большего треша представить сложно.

https://github.com/isocpp/CppCoreGuidelines/issues/1038

(since C++17) Ну возьми.

Давно доступно в clang(libc++), gcc(libstdc++) и msvc.

Ну и если почитать сообщения по ссылке, то можно найти:

So I think that after the lengthy discussion here, this issue can now be closed. In summary: the use-after-free potential with string_view is accounted for in the Lifetime profile, even if there may be bugs or limitations in preliminary implementations that mean it is not diagnosed.

https://imgur.com/a/bRCAbcr

C26484

Лайфтаймы в С++ 2019 это реальность, благодаря MSVC и Clang.

Вау, 1% фич Rust теперь C++. Бегом переписывать всё снова на С++.

https://github.com/isocpp/CppCoreGuidelines/issues/1038

test.cpp:7:25: error: object backing the pointer will be destroyed at the end of the full-expression [clang-diagnostic-dangling-gsl,-warnings-as-errors]
  std::string_view sv = s + "World\n";

Бегом переписывать всё снова на С++.

Пока еще особо и нечего назад переписывать.

Если бы он был разумно спроектирован и продуман, то осваивать его можно было бы быстро и через пару недель начинать писать на нём. Как на go, например.

осваивателей ЯП «за две недели» надо топить, пока они маленькие ещё.

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

А теперь давайте проверим многопоточный код.

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

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

Ну или хотя бы инвалидацию итераторов.

В Visual C++ 2019 есть. По сути там как в Rust:

One rule classifies containers as an ‘Owner’. Then, when a non-const method is called on the Owner, its owned memory is assumed invalidated and iterators that point at the owned memory are also considered invalid.

В clang есть наработки на эту тему:

http://llvm.org/devmtg/2018-04/slides/Balogh-Finding%20Iterator-related%20Errors%20with%20Clang%20Static%20Analyzer.pdf

Они уже в clang, но они пошли более сложным путем, реально пытаясь анализировать - ломается итератор или нет. А значит это не так надежно и универсально как метод в Rust или Visual C++.

Или ещё лучше - пусть он мне найдет все неинициализированные переменные статически. Я так и не нашёл как это сделать.

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

Но можно легко написать свой чекер на питоне.

Вы точно поняли суть задачи?

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html

Я правильно понимаю, что оно работает только с кастомным мютексом и все переменные должны быть помечены вручную?

Вы точно поняли суть задачи?

Значит вы не описали свою просьбу достаточно информативно.

Я правильно понимаю, что оно работает только с кастомным мютексом и все переменные должны быть помечены вручную?

Нет, не только, в стандартной библиотеке есть все что надо. Что касается «должны быть помечены вручную», вы точно понимаете, что оно делает и что такое вообще «Thread Safety Analysis»?

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

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

Значит, очевидно, не в курсе и не понимаете, что это вообще такое.

Ну весело да, как кич некий, я ж не спорю об этом

ну тогда я тебя не понял )

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

ну а тут ты меня не понял, ни в одном месте я не ставлю это в один ряд с достойными вещами в интернетах

осваивателей ЯП «за две недели» надо топить, пока они маленькие ещё.

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

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

а fortran мертвый?

Вполне живой. Писал на нём программу в этом году, кстати.

Любой начинаюший сишник понимает в этом больше чем растер,

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