Вышел Rust 1.3

проблемы можно с обоими вариантами получить.

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

Реально.

С IQ ~200, ну или потратив ещё плюс год на поиск и изучение того, что в документации упущено.

Или ты хотел чтобы в описании каждой функции были все-все необходимые знания?

Документация по Java, C# или С++, вот примерно этого я хочу. Ну или хотя-бы пускай указывают с какого языка какую фичу скопировали. Вот откуда мне знать, что форматированый вывод строк пришел из С и это норма для системных языков? Я экстрасенс что-ли или яжпрограммист у меня такие вещи в ДНК коде должны быть прописаны?

Да, изменится. Индекс не нужно указывать, он сам по себе проявляется когда ты считаешь аргументы в функции —> сигнатуры становятся чище, можно отказаться от where, например.
Функции с больше чем 5 аргументов нечитаемы и встречаются редко, 1-2-3 — чаще всего, какие здесь сложности?
Лайфтаймы, как я понимаю, штука больше вспомагательная и мало используется. Вот зачем, зачем на неё сколько места выделять?

1-2-3 — чаще всего, какие здесь сложности?

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

Вот этот вариант более надёжным выглядит: Вышел Rust 1.3 (комментарий)

Господа, придумывающие альтернативный синтаксис, обобщите его и на этот пример

struct Example<'a, 'b: 'a, T: 'a, P: 'b>(&'a Box<Fn(T) + 'b>, &'a &'b P);

не весь шарповый код ты бы сходу легко читать начал

Не ввесь, но таких сложностей как с Rust уже точно не возникает. Что сложного в LINQ?)
Только что бегло просмотрел документацию — божетсвенная. Да и вообще, встретив где-нибудь такие запросы я бы понял без документации, ибо они прекрасно сами себя документируют. Там даже SQL не нужно знать и матан всякий, чтобы понять что это и зачем, можно сразу взять язык и работать с ним. Видно что Microsoft программистов уважает, а Mozilla своих — нет.

StringBuilder в Java я быстро схватил, когда читаешь — всё просто и логично. Строки в Rust, и рядом не стояли

Ну хоть бы to_String написали что-ли...

Проблевался.

Форматированый вывод, {}, конкатенация и т.д. выглядит некрасиво

ПХПфанат?

Почему записано &'a, это ссылка на лайфтайм

Осиль документацию уже. Или успокойся и вернись к любимому ПХП, или что у тебя там.

форматированый вывод строк пришел из С

Специалист!

Ну ты просто чудесный специалист по сишарпам, если думаешь, что форматирование в раст пришло из си.

Мало кто сейчас пишет код в блокноте без подсветки синтаксиса и автодополнения.

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

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

А лайфтаймы значит не дублирование, когда в трёх местах одно и то же пишешь, а используешь только однажды, ага. Да так пишешь что аж в одну строчку не помещается, нужно ещё вторую — where )))
Лучше бы лайфтаймы после этого where записывали.

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

struct Example<'a, 'b: 'a, T: 'a, P: 'b>(&'a Box<Fn(T) + 'b>, &'a &'b P);

Что же это мне напоминает? Ах, вот, обобщи синтаксис Питона вот на этот пример: программа из одной строчки ни Perl

Окей, только скажи пожалуйста, что нужно прочитать, какие ритуалы совершить, сколько девственниц принести в жертву, чтобы хоть как-то распарсить всю эту черную магию?

Проблевался.

В Rust 2 типа строк — какой из них to_string возвращает?
Вот это наверное самая первая вещь в Rust от которой я и проблевался.
А ещё создаётся впечатление, будто to_string делает примерно то же что и to_lowercase.

ПХПфанат?

Нет. Кстати, Rust по читаемости где-то и есть на уровне PHP, если не хуже

Осиль документацию уже.

Документация рассказывает что это, но она не рассказывает почему именно так, не иначе

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

форматированый вывод строк пришел из С

Специалист!
Ну ты просто чудесный специалист по сишарпам, если думаешь, что форматирование в раст пришло из си.

==============
Wikipedia:

Наиболее ярким представителем этого семейства является функция printf, а также ряд других функций с производными от printf названиями в стандартной библиотеке языка Си (являющейся также частью стандартной библиотеки Си++ и Objective-C).

==============
Анонимус, поясни. Скинь ссылку на первоисточник, а не на Педивикию, незнаю...

Можешь кинуть пруф нечитаемости PHP? А то я не припомню, чтоб мне было сложно его читать. Писать неприятно, да.

Насколько я понимаю, в Си++ ровно такая же проблема.

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

https://www.rust-lang.org/ Зацени код на главной и расскажи, где ты там увидел printf.

В любом популярном, мейнстримном языке посмотри, как работают со строками. Только не С, со своим printf

Я просил конкретных примеров. А то я щас посмотрю на популярные, мейнстримовые C++ и PHP и по результатам сделаю вывод о твоих вкусах.

Любой код на PHP будет хуже читаемым по сравнению с аналогичным кодом на Java. В основном из-за $,:: и ->

В 2.0 много ломающих изменений будет, это же очевидно, кэп.

Очевидно кому и почему?

Со строками, хуже всего это to_string. Ну хоть бы to_String написали что-ли...

Ты это серьёзно? Чем тебе to_string не угодило?

Ну и я правда не понимаю чем тебе не нравится конкатенация и форматированный вывод.

А ведь никто так и не сказал толком, зачем лайфтаймам отдельные имена.

Да хотя бы поэтому:

struct Test<'a, 'b> {
    a: &'a i32,
    b: &'b i32
}

fn test<'a, 'b>(a: &'a i32, b: &'b i32) -> Test<'a, 'b> {
    Test { a: a, b: b }
}

Почему лайфтайм в том месте, где записываются обобщенные типы; что общего, где связь?

Твой вариант? Сделать ещё одно место, где записывать лайфтамы? Типа

fn test['a, 'b]<T1, T2>(...)

Почему записано &'a, это ссылка на лайфтайм или это какая-то специальная ссылка или это что-то другое? Почему лайфтаймы называются a, b, c, места на что-то более осмысленное не хватает?)

Ответ на первый вопрос - «потому что». Или что ты услышать хочешь? Да, это лайфтам, «потому что правила языка такие». Может ещё спросишь почему ссылка - это «&»?

Не нравятся a, b, c - пиши что-то более длинное, никто не запрещает. Как правило, и так понятно, потому и не пишут. Аналогично с типами - им принято давать короткие имена, это не только в расте так. Кстати, я не всегда этому правилу следую, если кажется, что так будет проще читаться.

Хотя-бы так:

Лайфтайм у тебя это «@»? Почему он только один выходной? Или как это понимать?

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

Синтаксис уже устоялся, то что он тебе не нравится - это совсем другой вопрос.

Документация вполне неплохая, к ней какие претензии? Для нового языка очень и очень неплохо. Можно вспомнить как D стартовал - по нему и сейчас литературы немного. А некоторое время назад была аж одна платная книга. Сравни с растом - несколько вполне неплохих мануалов, причём есть как официальные так и нет. Документация по всему из стандартной библиотеки присутствует.

API стабильное. Или ты о чём вообще?

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

Возможно. Но я хотел бы несколько примеров сложностей. Да, в расте можно не знать, что 'a лайфтайм. Но если ты его не укажешь когда надо, то тебе компилятор про это напишет и скажет, что это лайфтайм. А дальше гуглится уже элементарно. Ещё примеры?

С IQ ~200, ну или потратив ещё плюс год на поиск и изучение того, что в документации упущено.

Ну не надо этого, а то я себя гением почувствую. Ещё раз: есть официальный мануал, который начинает с основ, есть «раст бай экзампл», который тоже всё разжовывает. Если что-то непонятно, то можно погуглить конкретный вопрос или «даже» спросить. Причём ответят и на русском - хотя бы на этом форуме. Это так сложно или как?

Ну и мне очень хочется увидеть несколько примеров «упущений в документации».

Ну или хотя-бы пускай указывают с какого языка какую фичу скопировали.

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

Я экстрасенс что-ли или яжпрограммист у меня такие вещи в ДНК коде должны быть прописаны?

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

Вот давай о форматировании строк. Что там сложного/противоестественного? В C#, который тебе показался лёгким, сильно иначе сделано?

Что сложного в LINQ?)

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

StringBuilder в Java я быстро схватил, когда читаешь — всё просто и логично.

Для этого надо о нём знать. Если не знать, при манипуляции строками «хорошего качества код» не получится. Это просто пример того, что хоть что-то по языку почитать надо.

Видно что Microsoft программистов уважает, а Mozilla своих — нет.

Ну-ну. Или просто языки разного уровня.

А ещё в шарпе есть вещи типа "?.". Так что майкрософт тоже не гнушаются «закорючки» использовать.

Да и чем форматирование строк от раста сильно отличается?

var s = String.Format("{0} is {1} year{{s}} old", p.Name, p.Age);

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

Глупости какие-то.

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

Покажи пример. Я вижу только одно «объявление» и несколько «использований» - всё честно.

Да так пишешь что аж в одну строчку не помещается, нужно ещё вторую — where )))

where не (только) для этого. Много строчек и без этого лепить, зато оно дают дополнительные возможности.

struct Example<'a, 'b: 'a, T: 'a, P: 'b>(&'a Box<Fn(T) + 'b>, &'a &'b P);

Давай так попробуем:

template <scope a, scope b, type T, type P>
where @b outlives @a
struct Example(ref@a Box<Fn(T@a)@b>, ref@a ref@b P);

Хм. В любом случае, выглядит безобразно...

В Rust 2 типа строк — какой из них to_string возвращает?
Вот это наверное самая первая вещь в Rust от которой я и проблевался.

А ничего что в шарпе тоже два вида (String/StringBuilder)? А в джаве три - String, StringBuilder, StringBuffer. Причём это вполне себе «выскоуровневые языки». В С++ так вообще в стандартной библиотеке несколько и ещё много в разных либах/фреймворках.

to_string, как и следует из названия, возвращает String. Ведь второй тип - это &str. Не представляю как тут можно запутаться.

А ещё создаётся впечатление, будто to_string делает примерно то же что и to_lowercase.

Это с какой стати-то?

Документация рассказывает что это, но она не рассказывает почему именно так, не иначе

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

В любом популярном, мейнстримном языке посмотри, как работают со строками. Только не С, со своим printf

Давай подробнее. Чем вот это сильно отличается от раста:

Console.WriteLine("args1: {0} args2: {1}", value1, value2);

println!("args1: {0} args2: {1}", value1, value2);

А ничего что в шарпе тоже два вида (String/StringBuilder)? А в джаве три - String, StringBuilder, StringBuffer.

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

Документация рассказывает что это, но она не рассказывает почему именно так, не иначе

А она и не должна.

Вообще-то должна. Пусть кратко, пусть в основном отсылками к другим материалам, но должна.

С нуля выучить этот язык просто нереально.

Я одного человека, который никогда ничего не писал кроме скриптов, научил кодить на расте на заданиях, rustbyexample и документации. Сначала было непросто, но потом он вполне освоился.
Что ещё расскажешь?

Вообще-то должна. Пусть кратко, пусть в основном отсылками к другим материалам, но должна.

Ну хз, мне всё-таки кажется, что это не задача документации. В том же С++ есть куча учебников/мануалов, а есть «design and evolution» для интересующихся. В расте у них ведь тоже отдельно есть краткое упоминание того, на что смотрели. Правда уж слишком краткое.

не было никакой необходимости для «string literal» придумывать в расте песни и танцы.

Слайс - это не совсем «string literal» или ты о чём?

Ну и почему лукавлю-то? Ведь идея такая же - мутабельная и иммутабельная сущности.

String, StringBuilder, StringBuffer

StringBuffer это устаревший класс, который почти не используют (я знаю только один случай, когда его надо использовать). По факту два класса.

Очевидно кому и почему?

Всем должно быть, мажорная версия: то что нельзя сломать в 1.5 можно сломать в 2.0. Судя по настроениям в коммьюнити, ломать есть что.

Ты это серьёзно? Чем тебе to_string не угодило?

Здесь: Вышел Rust 1.3 (комментарий)

чем тебе не нравится конкатенация и форматированный вывод

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

об именованых лайфтаймах:

Можно как-то так:

                    // с правой стороны пример с одним лайфтаймом
struct Test {                            //  struct Test {
    @a: &i32,                            //       @a: &i32,
    @b: &i32                             //        b: i32
}                                        //   }
                                         //
fn test(@a: &i32, @b: &i32) -> Test {    //  fn test(@a: &i32, b: i32) -> Test {
    Test { a: @a, b: @b }                //      Test { a: @a, b: b }
}                                        //  }
                            // Но так бы было лучше:
fn test(@a: &i32, @b: &i32) -> Test {    //  fn test(@a: &i32, b: i32) -> Test {
        a: @a, b: @b                     //          a: @a, b: b
}                                        //  }
                                   // А так ещё
fn test(@a,@b: i32) -> Test {            //  fn test(@a,b: i32) -> Test {
        a: @a, b: @b                     //          a: @a, b: b
}                                        //  }

Остальные вопросы

Думаю после этого куска кода там всё очевидно

Документация вполне неплохая, к ней какие претензии? Для нового языка очень и очень неплохо.

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

triple_brutal_facepalm.jpg

Люди, вообще не знающие языка, пытаются придумать для него синтаксис. Пора пополнять игнор-лист.

Я тебе советую поработать со строками в C. У тебя каша в голове судя по всему. Или ты не понимаешь целей Rust. Строки это достаточно сложная конструкция. В других языках она может выглядеть просто, но они платят определённую цену за это. Цель Rust — сделать строки удобнее, чем в C, но цену не платить. Сделать строки как в Python-е не выйдет при всём желании.

Но я хотел бы несколько примеров сложностей.

Допустим я открыл чужой код на GitHub — клонировать репозиторий лень \ нет времени \ нет трафика, как быть?
Да и в любом случае — компиляция, просмотр выводов это лишние телодвижения —> сложнее, особенно для тех кто ценит своё время.

я себя гением почувствую

Rust с нуля изучил? О_о
До этого вообще не программировал?

Если что-то непонятно, то можно погуглить конкретный вопрос или «даже» спросить. Причём ответят и на русском - хотя бы на этом форуме. Это так сложно или как?

Немного сложнее. Хотя это нормально, мы здесь как-то с темы сьехали.

несколько примеров «упущений в документации»:

Можно ли прочитав документацию понять вот это: Вышел Rust 1.3 (комментарий)
Если да, то прошу ткнуть меня носом в то, что упустил.

Неужели ты после этого пойдёшь изучать указанный язык и потом снова вернёшься к расту?

А что мне ещё остаётся делать? Откуда я должен узнать, что такое *, например ? Ну ладно, мне повезло однажды увидеть это в C, а что остальным людям делать?

Ну какой-никакой кругозор у тебя, по всей видимости, есть

Что делать тем, у кого нет этого кругозора? Да большинство узнав, что документацию нужно читать полностью и при этом активно гуглить, забудут о Rust как о кошмарном сне и больше не вспомнят.

Вот давай о форматировании строк.

print!(«Hello {}», world); vs print!(«Hello» + world); — что приятнее выглядит?

print!(«Hello {}», world); vs print!(«Hello» + world); — что приятнее выглядит?

1, конечно. А теперь добавь в конце восклицательный знак - где это будет проще?

print!(«Hello» + world)

И да, если ты в своей любимой Джаве так пишешь, у меня для тебя плохие новости.

StringBuilder в Java я быстро схватил, когда читаешь — всё просто и логично.

Для этого надо о нём знать.

Любой джуниор о нём знает. Всё детакльно расписано и задокументировано. Всё давно оптимизировано. Ну разве что кто-то создаст огромную петлю в которой будет соединять строки через '+' — получит по шее при первом же code review.

Или просто языки разного уровня

В данном случае документация разного уровня.

чем форматирование строк от раста сильно отличается?

Выше о форматировании был пример

Ну и почему лукавлю-то?

Ты можешь конечно не писать на жаве/c#, поэтому тупо не знаешь.

Ведь идея такая же - мутабельная и иммутабельная сущности.

Нет, основная идея — сделать быструю конкатенацию. В джаве еще есть непотокобезопасная версия. Это распространенный кейз, в остальном немутабельность никаким образом не мешает. И самое главное «string» это String, а не неведомая зверушка.

В расте я вижу, по крайней мере в servo — &str вовсю используется в клиентских интерфейсах, чтоб не сильно мозолили глаза to_string у литералов.

Глупости какие-то.

Нет же. Там выше скидывали жирный такой кусок кода, со складками. Если до него добавить where, —> { и разукрасить, то зрелище будет в любом случае ужасающим.

Покажи пример.

Здесь: Вышел Rust 1.3 (комментарий)

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

Оптимист, ахаха )))

Цель Rust — сделать строки удобнее, чем в C, но цену не платить.

Строки это строки, а массивы байт это массивы байт, к сожалению авторы раста этого не знают.

&str вовсю используется в клиентских интерфейсах, чтоб не сильно мозолили глаза to_string у литералов

Ишо один специалист прибежал! И откуда вы только берётесь?

StringBuffer это устаревший класс, который почти не используют (я знаю только один случай, когда его надо использовать). По факту два класса.

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

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

В джаве и шарпе один тип строки. Билдера используются максимально редко и в хорошем коде не передаются между уровнями абстракций. В отличие от &str/String

И откуда вы только берётесь?

Из растбука. Могу поспорить, через год добявят implicit cast литерала в String.

Из растбука.

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

Всем должно быть, мажорная версия: то что нельзя сломать в 1.5 можно сломать в 2.0.

И много сломали, скажем, в C#5?

Здесь: Вышел Rust 1.3 (комментарий)

Там ответа не нашёл, хотелось бы подробнее.

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

Давай конкретнее что именно не нравится в форматировании. С конкатенацией есть аж одна «проблема» - необходимость & добавить, если мы строки «складываем».

А в остальном — налетай, критикуй.

Из сигнатуры вообще не видно, что Test лайфтаймы использует. Ну и оставив один лайфтайм ты здорово упросил себе дело, тут как раз более сложный пример интересен.

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

Дык, никто и не говорит, что её планируют забросить.