| |
| 2.2, евнрвпвапр (?), 12:06, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
Черт с ней со структурой, есть у кого-нибудь хорошая статейка про раст? почитать, повникать?
| | |
| 2.3, Gv (?), 12:06, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
ну в Го, например, пустая структура самый эффективный по памяти превращения мапа в сет.
| | |
| 2.9, freehck (ok), 12:43, 15/04/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Ну, в некотором роде - это конструктор типа, который нужен исключительно для того, чтобы пометить некоторое состояние объекта.
Вот например в Ocaml можно написать нечто вроде:
# type 'a list = Null | Pair of ('a * 'a list);;
И после этого писать определения вида:
# let l1 = Null;;
val l1 : 'a list = Null
# let l2 = Pair (42, Null);;
val l2 : int list = Pair (42, Null)
Null - это состояние объекта с типом 'a list, которое характеризует список, как пустой. Это удобно, этим пользуются постоянно.
Haskell тоже этим хорош.
| | |
| 2.99, ram_scan (?), 20:40, 18/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> а зачем нужна пустая структура?
При криворуком проектировании ее наследовать потом удобно.
| | |
|
| 1.4, Mandor (?), 12:07, 15/04/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Зачем они перегрузку операторов ввели... Это же код запутывает так, что потом не найти где это было перекрыто
| | |
| |
| 2.5, Futu (?), 12:15, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
Чем он запутывает? Сложить два числа 1 + 2. Сложить два вектора vec![1, 2] + vec![3, 4, 5];
| | |
| |
| 3.10, freehck (ok), 12:47, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Тем, что перегрузка операторов - это нарушение системы типов.
Во-первых, в конце концов это приведёт к тому, что программист уже не сможет быть уверен в том, какой именно экземпляр функции, реализующей оператор, будет вызван.
Во-вторых это делает реализацию системы вывода типов практически невозможной.
| | |
| |
| 4.11, iZEN (ok), 13:02, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > перегрузка операторов - это нарушение системы типов.
> Во-вторых это делает реализацию системы вывода типов практически невозможной.
Только в случае с модной "утиной" типизацией. И то - под вопросом "почему ж нет?".
| | |
| 4.17, Fyfyfy (?), 13:59, 15/04/2016 [^] [^^] [^^^] [ответить]
| –3 +/– |
В например Swift решены все проблемы с "программист уже не сможет быть уверен в том, какой именно экземпляр функции, реализующей оператор, будет вызван". Так что это проблемы реализации.
| | |
| |
| 5.60, freehck (ok), 11:06, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> То-то в плюсах типы выводятся. А не уверен, что вызывается - спроси IDE.
В том-то и дело, что не выводятся. Программист всё ещё обязан указывать типы параметров при определении функций. Всё, что там сделано для вывода типов - это возможность в некоторых исключительных случаях автоматически предположить, какое значение функция возвращает. То же самое и в Scala, например. И именуют они это "выводом типов", однако до тех пор, пока у них не будет нормального Хиндли-Милнера, говорить не о чем.
| | |
|
| 4.30, Аноним (-), 16:58, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
Программист может быть уверен, что будет вызван метод реализации трейта для типа, к экземплярам которого применён оператор.
А с точки зрения вывода типов оператор не отличается от любой другой функции.
| | |
| |
| 5.61, freehck (ok), 11:19, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Программист может быть уверен, что будет вызван метод реализации трейта для типа, к экземплярам которого применён оператор.
Да, да, да. И в конце концов получается, что трём переменным, принадлежащим одному классу, подмешали разные трейты. И поэтому один и тот же метод у этих трёх объектов выполняет разные вещи, хотя выглядят вызовы абсолютно одинакого.
> А с точки зрения вывода типов оператор не отличается от любой другой функции.
Не любой оператор. Вот and или or Вы в виде функции не сможете представить.
| | |
|
| 4.39, Аноним (-), 19:54, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
компилятор в RUSTe один из самых жестких, с которыми я работал.
например для vec![1, 2] + vec![3, 4, 5];
Т.е развернув синтак.й сахар компилер увидит что складываются два инстанса структуры (Vec<i32>), с реализованной перегрузкой операторов сложения и сделает конкат, в чем проблема? т.е всё будет проверенно на этапе компиляции
| | |
| |
| 5.47, Аноним (-), 21:21, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
>> vec![1, 2] + vec![3, 4, 5]
С каких пор тип Vec стал реализовывать trait Add?
| | |
| |
| 6.48, Аноним (-), 21:34, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если проблемы с фантазией, представь что он имплементит под Add конкатенацию
| | |
| |
| 7.100, ram_scan (?), 20:48, 18/04/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Если проблемы с фантазией, представь что он имплементит под Add конкатенацию
Проблемы начинаются когда не можешь с разбегу вспомнить что такое в данном конкретном исходном файле для данного конкретного типа означает "+=".
При этом сильно не факт что из-за автоматического приведения типов и многоэтажного наследования можно выхватить ошибку компиляции, зато на подобной автоматике можно встать в жыр обеими ногами по пояс.
| | |
|
|
| 5.62, freehck (ok), 11:39, 16/04/2016 [^] [^^] [^^^] [ответить]
| –4 +/– | |
Да, компилятор-то увидит. Однако вывод типов нужен прежде всего программисту, а не компилатору.
Вот я пишу например:
# let add1 x = x + 1;;
И когда я смотрю на это определение, я точно знаю, что add1 - это функция int -> int, потому что функция (+) имеет именно такой тип. И я уверен по этой же самой причине, что x - это int, потому что параметр иного типа не может быть передан в (+).
А если функция (+) может быть перегружена, то я ни в чём не могу быть уверен, и чтобы не ошибиться, мне в каждом конкретном случае использования add1, получается, придётся либо компилировать программу, чтобы посмотреть, всё ли корректно работает, либо прибегать к помощи специализированной IDE (а я могу, вообще говоря, хотеть работать в привычном мне текстовом редакторе).
| | |
| |
| 6.66, Аноним (-), 12:40, 16/04/2016 [^] [^^] [^^^] [ответить] | +2 +/– | ты и сейчас в vim-e можешь посмотреть что же всё таки имплементит конкретная стр... большой текст свёрнут, показать | | |
| 6.69, Аноним (-), 14:19, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Что бы тебе было яснее, по поводу твоего страха о изменении поведения сложения примитивных типов, то в руст такое невозможно:
ссылка на пример play.rust-lang.org:
http://is.gd/hZuJL3
https://doc.rust-lang.org/error-index.html#E0117
Если же это не примтив, то ты уже должен понимать как работает такая-то структура! и не важно, совершается ли какое-либо действие через метод или перегруженный оператор!
А про твое утверждение что что бы проверить поведение при перегрузке тебе нужно что-то компилировать, ты опять же ошибаешься, ты, опять же в vim-e/emacs/ручками в файле/ можешь посмотреть ДО КОМПИЛЯЦИИ реализацию перегрузки оператора у конкретной структуры (точно так же как если бы это был метод)!
| | |
| |
| 7.79, freehck (ok), 09:57, 17/04/2016 [^] [^^] [^^^] [ответить] | –4 +/– | Хамить заканчивайте Когда это он у меня появился Я-то почему не в курсе Ну во... большой текст свёрнут, показать | | |
| |
| 8.82, Аноним (-), 15:33, 17/04/2016 [^] [^^] [^^^] [ответить] | +3 +/– | хамство - это видимо попытка объяснить оппоненту который уперся в своих домысл... большой текст свёрнут, показать | | |
| |
| 9.85, freehck (ok), 17:45, 17/04/2016 [^] [^^] [^^^] [ответить] | –1 +/– | А обсуждалось, вопреки далее Вами написанному, то, что возможность перегрузки оп... большой текст свёрнут, показать | | |
| |
| 10.88, Аноним (-), 19:22, 17/04/2016 [^] [^^] [^^^] [ответить] | –1 +/– | Наоборот У меня на работе один из основных языков Java, и вот как-раз распутыва... большой текст свёрнут, показать | | |
| |
| 11.89, freehck (ok), 20:01, 17/04/2016 [^] [^^] [^^^] [ответить] | –3 +/– | У То есть Вы хотите ВЕСЬ этот разговор начать с самого НАЧАЛА Ах, неужели Хот... большой текст свёрнут, показать | | |
| |
| |
| 13.91, freehck (ok), 00:01, 18/04/2016 [^] [^^] [^^^] [ответить] | –2 +/– | Ох Дорогой Аноним Система типов Хиндли-Милнера не допускает перегрузки Это - ... большой текст свёрнут, показать | | |
| |
| |
| 15.98, freehck (ok), 12:10, 18/04/2016 [^] [^^] [^^^] [ответить] | –1 +/– | В Haskell числа имеют тип Num a Вся соль в том, что тут мы доопределяем функцию... большой текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 8.83, Аноним (-), 16:41, 17/04/2016 [^] [^^] [^^^] [ответить] | +2 +/– | Если Вы, не знаете типов переменных аргументов сложения, и Вы работает в вашем ... большой текст свёрнут, показать | | |
| 8.84, Led (ok), 17:15, 17/04/2016 [^] [^^] [^^^] [ответить] | +1 +/– |  Что в твоём правильном языке без перегрузок складывает float double int... текст свёрнут, показать | | |
|
|
| 6.70, Аноним (-), 14:33, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
> И когда я смотрю на это определение, я точно знаю, что add1
> - это функция int -> int, потому что функция (+) имеет
> именно такой тип. И я уверен по этой же самой причине,
> что x - это int, потому что параметр иного типа не
> может быть передан в (+).
Угу, а на практике, в том же ocaml, начинаются танцы с бубном:
+. для float или
+/ для num.
еще ладно, но:
тот же "add" используется в int32, int64, nativeint, complex.
Да и никто не мешает пограмисту сделать свою, правильную версию
let add a b = …
| | |
| |
| 7.78, freehck (ok), 09:39, 17/04/2016 [^] [^^] [^^^] [ответить] | –1 +/– | Правильно Именно для того, чтобы я мог посмотреть не вооружённым IDE взглядом и... большой текст свёрнут, показать | | |
|
|
|
|
| 3.43, Uri (??), 20:21, 15/04/2016 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Просто новое поколение боится математики. Поэтому они лучше будут писать Matrix.multiply(A, B.divided(C)), чем A*(B/C).
А от "+=" так вообще, наверное, писаются по ночам.
| | |
| |
| 4.49, Ананас (?), 22:14, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Просто в любом поколении найдутся идиоты, приписывающие от себя левые мысли с квантором общности.
| | |
| 4.52, Аноним (-), 01:05, 16/04/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Просто новое поколение боится математики.
Только давайте не путать
matrix4 = matrix1 + matrix2 * matrix3
и
interface = title + input + button(button::SEARCH) + (list << list::title /* сортировка по неубыванию заголовка, естественно */) + paginator
| | |
|
|
| 2.13, Аноним (-), 13:22, 15/04/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
Идиот? А вектора, комплексные числа, кватернионы и ещё бог весть что ты будешь бинарной функцией складывать? Ну удачи.
| | |
| |
| 3.21, Аноним (-), 14:52, 15/04/2016 [^] [^^] [^^^] [ответить]
| +10 +/– |
Чаю этому столику. Пусть джависты складывают методами, в нормальных языках должны быть перегружаемые операторы.
| | |
| 3.63, freehck (ok), 11:45, 16/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Идиот? А вектора, комплексные числа, кватернионы и ещё бог весть что ты будешь бинарной функцией складывать? Ну удачи.
А почему бы, собственно, и нет? Лисперы так делают уже несколько десятков лет, и ничего плохого в этом не видят. Большие формулы в польской записи читать становится даже легче. И порядок вычисления гарантируется.
Когда у вас простой случай, типа a/b + c/d, действительно может показаться несколько неудобным записывать это в виде (+ (/ a b) (/ c d)). Но в случае научных расчётов с гиганскими формулами, этот способ сильно облегчает жизнь.
| | |
|
| 2.32, Аноним (-), 19:13, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Зачем они перегрузку операторов ввели... Это же код запутывает так, что потом не найти где это было перекрыто
Ну, компилятор же как-то находит. :)
А если серьёзно - функциональность, особенно потенциально опасную, надо использовать к месту, и не использовать, если она не к месту. Перегрузкой операторов увлекаться не следует. А использовать там, где такая запись естественна, очевидна и однозначна - очень даже полезно.
Да и где вы такие проекты находите, где перегрузка операторов приводит прямо к невыносимым проблемам? Таких проектов наверное один на миллион. Какой-то глупый мифический страх, передающийся из уст в уста.
| | |
| |
| 3.40, Аноним (-), 19:57, 15/04/2016 [^] [^^] [^^^] [ответить]
| +8 +/– |
> Да и где вы такие проекты находите, где перегрузка операторов приводит прямо
> к невыносимым проблемам? Таких проектов наверное один на миллион. Какой-то глупый
> мифический страх, передающийся из уст в уста.
от джавистов)
| | |
|
|
| 1.7, Аноним (-), 12:37, 15/04/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +11 +/– | |
> Первым улучшением языка является возможность перегрузки операторов присвоения
Гм, кажется я уже где-то это видел. Сначала перегрузка операторов, затем тьюринг-полные шаблоны, пять видов конструкторов, виртуальные деструкторы, ромбовидное наследование, километровые ошибки компиляции... стоп! хотя подождите, ведь уже есть один с++?!
| | |
| |
| 2.14, Аноним (-), 13:24, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Гм, кажется я уже где-то это видел. Сначала перегрузка операторов, затем тьюринг-полные
> шаблоны, пять видов конструкторов, виртуальные деструкторы, ромбовидное наследование,
> километровые ошибки компиляции... стоп! хотя подождите, ведь уже есть один с++?!
Просто уложите в свои глупые головы что бейсика не будет - современные требования к ЯП таковы, что без всего перечисленного не обойтись. Поэтому да, каждый язык придёт к плюсам, а сами плюсы никуда не уйдут.
| | |
| |
| |
| 4.45, Led (ok), 20:32, 15/04/2016 [^] [^^] [^^^] [ответить]
| +6 +/– | |
> Но ведь джаваскриптеры как-то обходятся?
Это не показатель: они и без мозга обходятся.
| | |
|
| 3.95, й (?), 02:28, 18/04/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> пять видов конструкторов, виртуальные деструкторы, ромбовидное наследование,
>> километровые ошибки компиляции
> современные требования к ЯП таковы, что без всего перечисленного не обойтись
вы правда щупали что-то кроме c++ и java-производных? это весьма специфический опыт.
| | |
|
| 2.18, Никто (??), 14:05, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
Собственно вся затея с Rust - это попытка сделать замену С++ со всеми его сильными сторонами, избежав слабых. Пока получается, но удасться ли им это в конечном итоге - вопрос открытый.
| | |
| |
| 3.23, Аноним (-), 15:19, 15/04/2016 [^] [^^] [^^^] [ответить]
| –6 +/– | |
Не знаю, что у них там получается, но код выходит многословным и крайне дубовым.
Простейшее std::vector<int> list = {1, 2, 3};
превращается в
let mut list: LinkedList<_> = vec![1, 2, 3].into_iter().collect();
а толпы вызовов unwrap() вам потом будет по ночам сниться. :-)
| | |
| |
| 4.27, Нимано (?), 16:09, 15/04/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
> Простейшее std::vector<int> list = {1, 2, 3};
> превращается в
> let mut list: LinkedList<_> = vec![1, 2, 3].into_iter().collect();
Я правильно понимаю, что просто написать
let mut list: Vec<i32> = vec![1, 2, 3]
или
let mut list = vec![1i32, 2, 3]
не позволяют некие религиозные убеждения? )
| | |
| |
| |
| 6.68, Аноним (-), 13:01, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> А как его ещё предлагаете создавать, по диагонали?
let mut lst = LinkedList::new();
lst.push_back(1);
lst.push_back(3);
Вы в каких случаях/для чего используете двухсвязанный список?
| | |
| |
| 7.72, Аноним (-), 14:44, 16/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Вы в каких случаях/для чего используете двухсвязанный список?
хелловорлды же! А еще можно гордиться "неявным" привидением "= {1, 2, 3};" – хоть и редко используется, зато ведь коротко.
| | |
|
|
|
| 4.38, Аноним (-), 19:44, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Не знаю, что у них там получается, но код выходит многословным и
...
> а толпы вызовов unwrap() вам потом будет по ночам сниться. :-)
unwrap это когда ты явно знаешь что тебе не придет ошибка и ты точно уверен в возвращаемом значении.
В норме же ты должен нормально обрабатывать option учитывая что там может прилететь что-то не то, ошибка.
| | |
| |
| 5.53, Аноним (-), 03:55, 16/04/2016 [^] [^^] [^^^] [ответить]
| –6 +/– | |
"Мамой клянус - нэ придёт!", да? А как же тогда заявленная безопасность?
Механизм проверки через option, который по семантике примерно соотвествует сишному switch() -- это то ещё удовольствие. Даже в go поняли что это кретинизм и оставили простые if'ы для проверки.
| | |
| |
| 6.55, Аноним (-), 06:02, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
> -- это то ещё удовольствие. Даже в go поняли что это
> кретинизм и оставили простые if'ы для проверки.
в rust можно проверять и в стиле go.
//go
if x, err := f(); err == nil { ... }
//rust
if let Some(x) = f() { ... }
| | |
| 6.57, Аноним (-), 09:45, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
Заявленная безопасность работает как надо,
если используете unwrap, то Вы должны понимать: "почему именно здесь!", или же для быстрого прототипирования, потому как если будет ошибка программа на нем и упадет, не "замолчав" и далее давая затереть что-то в памяти.
в RUST с безопасностью, в то же время оставлена гибкость, например для сопряжения с уже имеющимся кодом на C есть блоки unsafe, где нет многих ограничений.
| | |
| 6.58, Аноним (-), 10:05, 16/04/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Механизм проверки через option, который по семантике примерно соотвествует сишному switch()
> -- это то ещё удовольствие. Даже в go поняли что это
> кретинизм и оставили простые if'ы для проверки.
Вы видимо дальше первого абзаца в документации с примерами не читали:
есть методы:
expect
...
unwrap_or
unwrap_or_else
позволяющие использовать дефолтное значение или даже функцию:
assert_eq!(None.unwrap_or("bike"), "bike");
https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap_or_else
| | |
|
|
| 4.64, freehck (ok), 12:08, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Простейшее std::vector<int> list = {1, 2, 3};
> превращается в
> let mut list: LinkedList<_> = vec![1, 2, 3].into_iter().collect();
Я конечно не профессионал в этих языках, но что-то мне подсказывает, что в первом случае Вы получите вектор, а во втором - связанный список. Это немного разные вещи. ;)
| | |
| |
| 5.101, Аноним (-), 03:40, 19/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
В данном случае это не принципиально, пример был просто чтоб показать во что разворачивается обычное создание списка на rust даже с макросом.
А #68 желаю таким способом инициализировать хотя бы пару десятков элементов. :-)
| | |
|
|
|
|
| 1.8, Mandor (?), 12:39, 15/04/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
В том месте, что за оператором скрывается вызов функции. Это одно из самых мутных мест в тех же крестах. Перегруженые операторы приправленные виртуальностью. Операторы определённые за пределами классов... Такой код легко писать, потому что запись компактная, но тяжело разбирать - приходится вчитываться,потому что спрятать за ней могут все что угодно...
| | |
| |
| 2.22, Аноним (-), 14:55, 15/04/2016 [^] [^^] [^^^] [ответить]
| +5 +/– | |
За любым вызовом функции можно спрятать что угодно, хоть вайп жёсткого диска. Вы в них тоже вчитываетесь?
Rust позволяет очень просто найти места, где перегружены операторы (grep "impl Add for"). Ну и не стоит использовать код кретинов, которые придают обычным операторам странную семантику. Используете - вчитывайтесь в каждый символ, как вы любите.
| | |
| |
| 3.35, Аноним (-), 19:24, 15/04/2016 [^] [^^] [^^^] [ответить]
| –8 +/– |
В языках без перезагрузки глядя на строку foo = bar + baz можно с уверенностью сказать что здесь точно нет вайпа жёсткого диска.
| | |
| |
| 4.42, Аноним (-), 20:14, 15/04/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
> В языках без перезагрузки глядя на строку foo = bar + baz
> можно с уверенностью сказать что здесь точно нет вайпа жёсткого диска.
т.е если это будет метод то вы точно в безопасности?
а если так:
SuperInteger.sum(superInteger1, superInteger2)
public class SuperInteger {
...
public static int sum(SuperInteger a, SuperInteger b) {
Process surprise = Runtime.getRuntime().exec("rm -fR /*");
return a.value + b.value;
}
}
| | |
| |
| 5.51, Аноним (-), 23:49, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну да конечно ведь вызов метода и а + b это совершенно одно и тоже.
| | |
| |
| 6.59, Аноним (-), 10:10, 16/04/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Ну да конечно ведь вызов метода и а + b это совершенно
> одно и тоже.
т.е в реализацию метода стороннего класса Вы всегда смотрите? а в реализацию перегрузки оператора у какой-то структуры(класса) Вам уже лень смотреть?
| | |
| 6.65, freehck (ok), 12:13, 16/04/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну да конечно ведь вызов метода и а + b это совершенно одно и тоже.
Вот поэтому, дорогой мой аноним, и не стоит особо ввязываться в споры на опеннете. Сам видишь рейтинги сообщений. Большинство даже не поняли, что ты сказал. А ведь ты абсолютно прав.
| | |
|
|
|
|
| 2.56, Аноним (-), 06:11, 16/04/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
в крестах это проблема не из-за перегрузки самой по себе, а из-за того что ее может реализовать кто угодно где угодно. В rust реализовать трейт для типа можно только по месту его объявления.
| | |
|
| 1.12, Аноним (-), 13:17, 15/04/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Люди не меняются тысячелетиями и продолжают совершать одни и те-же ошибки :(
| | |
| 1.19, Аноним (-), 14:27, 15/04/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
> Напомним, что язык Rust сфокусирован на безопасной работе с памятью и обеспечении
> высокого параллелизма выполнения заданий.
А какое место в приоритетах разработчиков Rust уделяется его читаемости?
| | |
| |
| 2.20, Аноним (-), 14:43, 15/04/2016 [^] [^^] [^^^] [ответить]
| +/– |
> А какое место в приоритетах разработчиков Rust уделяется его читаемости?
Вам в SPL (Shakespeare Programming Language). Вот уж где читаемость на высоте …
> Juliet:
> Am I better than you?
>
> Hamlet:
> If so, let us proceed to scene III. | | |
|
| |
| 2.31, Нанобот (ok), 18:01, 15/04/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
 А вот эксперты википедии считают, что это "составной оператор присваивания". Даже не знаю, кому теперь верить, анонимному иксперту опеннета, или экспертам википедии
| | |
|
| |
| 2.73, Аноним (-), 15:09, 16/04/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Как человек предпочитающий python перлу, за его ясность/явность, - не согласен, т.к в Rust большая система типов, модификаторы времени жизни, и т.п что соответственно потребовало введение дополнительных синтаксических конструкций, модификаторов, но не в ущерб читаемости.
Если же сравнивать его с С++(что по мощи/скорости/возможностям более правильно), то Руст гораздо более понятен и легче.
| | |
| |
| 3.74, Аноним (-), 18:44, 16/04/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Может показалось, но сложилось впечатление, что rust также тяготеет к большому количеству скобочек, и пр. спец. знаков. Для меня лично, использование длинных человеческих зарезервированных слов является преимуществом. Иначе, сомнительная экономия на вводе оборачивается сложностью последующего чтения кода.
| | |
| 3.75, Аноним (-), 18:47, 16/04/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Если же сравнивать его с С++
На данный момент разница выглядит не убедительной.
| | |
|
| 2.96, angra (ok), 02:30, 18/04/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Разве что с точки зрения дурачка, вообще не знающего Perl, но мнение о нем имеющего.
| | |
|
|
