/*
*//*
*
*
*/
#
Можна описати функцію і список параметрів, що вертає
Потім докерами задокументувати
А ще закоментити великий кусок кода швидко
решітку ніколи не використовував
В Раст така ж ідея
/// от тут іде опис
/// і параметри
/// і приклад
/// але три похилих лінії... це дофіга
Мова про те, що cинтаксис Rust намагались зробити мінімальістичним, а потім таке бачиш, і відразу запитання виникають: как, зачем, почему
Це відповідь на
нафіга такий коментар
Хочу сконцентруватись на суті, а не відвоілкатись на переклад невідомого.
Я читаю про С англійською, норм іде, і навіть комфортно, бо не потрібно думати, яке ж саме слово має на увазі російський переклад.
Коли писатиму, то ясен пень, що доки англ.мовою будуть. А зараз хочу без напрягу, по-швидкому.
Згоден, згоден.
Я вже давно ніякої іншої крім англійської в пошукових запитах не використовую, і оточення на компі теж виключно англ.мовою.
Просто так склалось, побачив, що люди закінчили переклад... а тут ще на очі попадалось пару статей, який класний Раст... прям як зорі збіглись
І я якраз мав засіти і вчити якусь низькорівневу мову.
Так що от так от.
И три точки в rust'е есть... Но они не используются для slice'ов. И можно только в for'е или в match'е писать
Note that slicing is "exclusive" (so [n..m] is the interval n <= x < m), while .. in match patterns is "inclusive". To avoid confusion, we propose to change the match notation to ... to reflect the distinction. The reason to change the notation, rather than the interpretation, is that the exclusive (respectively inclusive) interpretation is the right default for slicing (respectively matching).
Some other languages (like Python and Go -- and Fortran) use : rather than .. in slice notation. The choice of .. here is influenced by its use elsewhere in Rust, for example for fixed-length array types [T, ..n]. The .. for slicing has precedent in Perl and D.