LINUX.ORG.RU

Rust 1.6

 ,


2

3

Команда разработчиков Rust рада представить первый в этом году релиз Rust — 1.6. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме. Как обычно, вы можете установить Rust 1.6 с соответствующей страницы на официальном сайте, а также посмотреть примечания к выпуску на GitHub. Выпуск включает в себя около 1100 патчей и содержит ряд небольших улучшений, одно важное изменение, а также изменение на Crates.io.

Стабилизация libcore

Самым большим нововведением в 1.6 является стабилизация libcore. Стандартная библиотека Rust состоит из двух уровней: небольшая базовая библиотека libcore и полная стандартная библиотека libstd, которая построена на основе libcore. libcore является полностью платформонезависимой, и требует только горстку внешних функций. libstd строится на основе libcore, добавляя поддержку выделения памяти, операций ввода-вывода и параллелизма. При использовании Rust во встраиваемых средах и при написании операционных систем, разработчики часто избегают libstd, используя только libcore.

Стабилизация libcore являтся важным шагом к возможности писать самое низкоуровневое ПО, используя стабильный Rust. Это позволит развиваться экосистеме библиотек вокруг libcore, но приложения пока полностью не поддерживаются. Ожидайте изменения в этой области в будущих релизах.

Стабилизации библиотеки

Около 30 библиотечных функций и методов теперь являются стабильными в 1.6. Заметные улучшения включают в себя:

  • Семейство функций drain() для коллекций. Эти методы позволяют перемещать элементы из коллекций, сохраняя память, в которой они размещены, тем самым снижая выделение памяти в некоторых ситуациях.
  • Ряд реализаций типажа From для конвертирования между типами стандартной библиотеки, в основном между целочисленными типами и числами с плавающей точкой.
  • Наконец, Vec::extend_from_slice(), ранее известный как push_all(). Этот метод существенно быстрее, чем более общий метод extend().

Crates.io запрещает использование масок в версиях зависимостей

Если вы являетесь мейнтейнером контейнера на Crates.io, возможно вы видели следующее предупреждение:

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

Другими словами, это запрещено:

[dependencies]
regex = "*"

Вместо этого вы должны указать конкретную версию или диапазон версий, используя одну из опций: ^, ~, или =.

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

>>> Официальный анонс

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 6)

Ответ на: комментарий от shkolnick-kun

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

А о каком именно продукте идет речь?

//Психиатр

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

Go, когда-то он мог быть запущен на голом железе, но потом его перепрофилировали, после чего в Rust чудесным образом стали появляться фичи, необходимые для создания ядерного кода, а в наши дни сотни хипстеров на гитхабе пилят свои ОСи на Rust...

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

Да, долго выпиливали.

Чо, не срослось с теорией? %) А прикинь, еще в 2013 его не собирались выпиливать.

Кстати, его еще и обратно могут запилить.

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

Go, когда-то он мог быть запущен на голом железе

Ага, ага - untested, unmaintained code

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

хипстеров на гитхабе пилят свои ОСи на Rust

Ну, в твоей теории всё логично. Выглядит правдоподобно, что два сообщества решили «разойтись нишами». Но вот во что я ни за что не поверю:

сотни хипстеров на гитхабе пилят свои ОСи на Rust

Нет, чтобы оси писали на Rust, это пожалуйста. Очень подходящий для этого язык даже сейчас.

Но чтобы хипстеры... Нет.

//Психиатр

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

Чо, не срослось с теорией? %) А прикинь, еще в 2013 его не собирались выпиливать.

А было ли его использование обязательным, когда он был? Можно ли было обойтись без него? GC тормозные же, и не детерминированное WCET у них!

Кстати, его еще и обратно могут запилить.

Если как опцию,- норм... А зачем, если не секрет?

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

Смотрел исходники первых попавшихся проектов, в осносном, - тыренные с OSDEV ассемблерные вставки и довольно примитивные верхние уровни ядра.

Есть конечно профи, типа команд разрабов zinc или redox, у остальных все похуже будет...

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

А было ли его использование обязательным, когда он был? Можно ли было обойтись без него?

Нет. Да.

Если как опцию,- норм... А зачем, если не секрет?

Отомстить за всё корпорации добра и утопить Go, очевидно же! И, наверное, народ хочет писать на Rust, не заморачиваясь на управление памятью.

tailgunner ★★★★★
()

Не совсем про сабж, но надо куда-то вбросить.

Stephan T. Lavavej ‏@StephanTLavavej 19 дек. 2015 г.

The STL in VS 2015 Update 2 will be C++17-so-far FEATURE COMPLETE, as of N4567. Some LWG issue resolutions remain to be implemented.

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

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

Сначала запилили афинные типы, чтобы заморачиваться управлением ресурсами. Теперь запилят GC, чтобы не заморачиваться управлением памятью. Я апплодирую стоя! И потом (другие) люди говорят, что в С++ абстракции не сбалансированы. Оккам тихо плачет в сторонке...

:)

//Психиатр

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

Сначала запилили афинные типы, чтобы заморачиваться управлением ресурсами. Теперь запилят GC

GC в языке был с самого начала, насчет афинных типов я не уверен.

И потом (другие) люди говорят, что в С++ абстракции не сбалансированы. Оккам тихо плачет в сторонке...

Вам совершенно необходимо обсудить этот вопрос с (другими) людьми и Оккамом.

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

Точно так же, хватало противников, скажем, лямбд в плюсах - мнол жили и без них неплохо.

Анонимус отлично помнит как в старых крестосрачах плюсатые гоготали над блямбдами. Теперь это предмет гордости. Смогли, осилили! Вот так всегда: пока фичи в крестах нет, орут нинужна, как только комитет соизволит, носятся как с писаной торбой, всех учат еще как надо.

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

Точно так же, хватало противников, скажем, лямбд в плюсах - мнол жили и без них неплохо.

Анонимус отлично помнит как в старых крестосрачах плюсатые гоготали над блямбдами. Теперь это предмет гордости. Смогли, осилили! Вот так всегда: пока фичи в крестах нет, орут нинужна, как только комитет соизволит, носятся как с писаной торбой, всех учат еще как надо.

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

Вам совершенно необходимо обсудить этот вопрос с (другими) людьми и Оккамом

Я обсудил. Обыно делают либо афинные типы, либо сборщик мусора. Но не то и другое одновременно. Не мог бы и ты теперь обсудить и предложить обоснование, зачем в этом языке с афинными типами сборщик мусора?//Психиатр

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

Ох, тоже прошу прощения. Криворук.

//Психиатр

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

Я обсудил

Это изложение затасканных банальностей, а не обсуждение.

Обыно делают либо афинные типы, либо сборщик мусора. Но не то и другое одновременно.

«Обычно»? Можно несколько примеров?

зачем в этом языке с афинными типами сборщик мусора?

Затем же, зачем и в языке без афинных типов // К.О.

http://manishearth.github.io/blog/2015/09/01/designing-a-gc-in-rust/

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

«Обычно»? Можно несколько примеров?

Это академические заморочки. Ведь GC там был, а потом его выпилили. А потом хотят вернуть, потому что Weak<> сочли неудобным.

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

//Психиатр

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

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

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

Так воображаемый быдлокодер на расте с gc может вообще не врубиться в раст без gc, даже скомпилировать не сможет. Это посильнее фрагментации крестописак будет.

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

то вся семантика владения/одалживания идет лесом же

Нет, лесом она не идет. Просто возникают дополнительные проблемы по сопряжению ежа и ужа парадигм. Фишка в том, что введением GC они просто перекладывают проблему циклов с компилятора на рантайм. И чем больше куча, тем дороже обходится решение этой проблемы. GC не масштабируем более нескольких GB кучи, а для GUI вообще убийца плавности и отзывчивости. А могли бы просто выразить семантику слабых ссылок в виде аннотаций и сказать «товарищи, используем вот это вот для этого, и ваши волосы будут мягкими и шелковистыми, а глаза - белыми».

//Психиатр

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

«Обычно»? Можно несколько примеров?

Это академические заморочки.

Имена у этих заморочек есть?

Ну и по твоей ссылке видно, что дизайн языка всё-таки подтягивают по потребности servo.

Можно конкретнее? По моей ссылке я вообще не вижу изменений в языке. GC планируется как библиотечная возможность.

А могли бы просто выразить семантику слабых ссылок в виде аннотаций

Вот это было бы уже изменением языке. И насчет «могли бы» - это уже кто-то сделал?

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

Имена у этих заморочек есть?

Конечно. В каких-то языках GC нет, в каких-то — есть. Потому что не все реализуют именно линейные типы как основную характеристику. Это исследовательские языки со своими целями.

Можно конкретнее?

Можно. Они говорят о GC и «графах объектов» в контексте servo. Прямой ссылки на это в тексте нет, но где еще они могут сейчас найти столь сложные объектные графы, что очень нужен GC, если не в DOM?

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

GC планируется как библиотечная возможность.

Это — другое дело. Я этого момента не заметил. Хуки к компилятору + библиотечные алгоритмы на выбор.

И насчет «могли бы» - это уже кто-то сделал?

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

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

Обыно делают либо афинные типы, либо сборщик мусора. Но не то и другое одновременно.

«Обычно»? Можно несколько примеров?

Это академические заморочки.

Имена у этих заморочек есть?

Конечно.

Из 7 языков в 3 (Clean, Idris, Alms) заявлено наличие GC, так что сборка мусора в языках с афинными типами - обычная практика (кстати, раньше разработчики Rust считали, что у него линейная система типов).

Они говорят о GC и «графах объектов» в контексте servo.

Нет. Вопрос о графах часто задавали в reddit и он относится к любому графу.

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

Опять же - примеры есть?

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

Из 7 языков в 3 (Clean, Idris, Alms) заявлено наличие GC, так что сборка мусора в языках с афинными типами - обычная практика

Ну вот этого я и опасался. Ты, наверное, просто не в теме специфики академических языков. Это экспериментальный вещи, основная задача которых — обкатка идей. Ну и защита диссертаций по итогам. На них ничего серьезного не пишут, что потом нужно было бы годами поддерживать 24х7. Кто-то хочет смешать системы типов и добавляет GC до кучи, а кому-то он достается в наследство от нижележащей платформы.

Но если вникнуть в смысл линейных/афинных типов, то делать язык на их основе и добавлять GC — это все равно, что говорить: «Ребята, мы делали линейные типы и не доделали. Поэтому вот вам еще GC. Так, на всякий случай.»

кстати, раньше разработчики Rust считали, что у него линейная система типов

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

Человеческая логика неполна и противоречива. Человек — это мешок с когнитивными искажениями. Им подвержены все, особенно те, кто считает, что им не подвержены. Но, благодаря этой неполноте человек может приближенно решать некоторые логические задачи, которые машине пока не доступны, когда машина делает только точный вывод (полный перебор в пространстве логических выражений). Причем у каждого человека свой собственный личный профиль неполносты вывода. Два человека с существенно разными профилями неполноты логического вывода друг-друга не поймут, хотя самим себе будут казаться абсолютно разумными. Все холивары на ЛОРе сводятся именно к этому.

В результате этой разницы в механизмах вывода возникает impedance mismatch между программистом и языками с выразительными системами типов на основе логик. Это совсем не тривиальная задача, как «простое и предельно понятное» человеку сделать понятным компилятору так, чтобы он думал не бесконечность. Бодания программистов с компилятором С++ и шаблонными метапрограммами — это еще цветочки по сравнению с тем, что творится в этих самых академических языках. На них очень сложно написать что-то нетривиальное, поэтому никто на них ничего и не пишет.

И в этом смысле есть мнение, что Rust может постигнуть та же участь. Что программирование в семантике владения чего-то мнее тривиального, чем счетчик ссылок, может стать постоянной борьбой с компилятором. И в этом ключе разговоры про GC как раз и выглядят именно так: «Мы сделали афинные типы, но народ не понимает, как ими реально пользоваться, и очень просит просто вернуть GC. Давайте сделаем.» А разговоры про гибкость, которую приносит GC — это просто попытка представить проблему как не проблему.

Опять же - примеры есть?

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

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

А теперь они вынуждены навешивать на язык всё, что есть в С++, но еще нет в Rust.

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

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

Поясни, пожалуйста))

Конспирология.

DarkEld3r ★★★★★
()
Ответ на: комментарий от shkolnick-kun

Как ОЧЕНЬ СУРОВЫЙ имбедщик ответственно заявляю:

Для начала скажу - ты на С++ пишешь или на С? Если второе, то ты точно читал то, на что отвечаешь?

безопасность получается за счет применяемых архитектурных решений, а не за счет языка

Язык может поощрять те или иные решения.

один хрен мне придется unsafe во все дыры пихать

Ну-ну.

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

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

Где ты это видишь? Я что-то таких желаний не наблюдаю, может не там смотрю?

По моему, ГЦ делают для конкретной цели и как строго опциональную штуку. Я читал некоторые (признаюсь, не все) вещи типа «Designing a GC in Rust» и, судя по ним, нефига не получится «не заморачиваться» и применение ГЦ в коде будет явно видно.

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

Я апплодирую стоя! И потом (другие) люди говорят, что в С++ абстракции не сбалансированы. Оккам тихо плачет в сторонке...

Я бы не советовал делать глобальные выводы по словам одного человека на форуме.

Насколько мне известно, GC делают для конкретной дели и как исключительно опциональную вещь. Сомневаюсь, что в таком виде, сборка мусора будет повсеместно использоваться. Если на то пошло, то в плюсах тоже есть механизмы для GC.

Впрочем, я точно так же как tailgunner, могу чего-то не знать.

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

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

Всё так, с одной поправкой - не в плюсах, а «везде», ну кроме языков которые легко расширяются «собственными силами».

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

Я обсудил.

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

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

Раскрой тему что ли.

Почитай, пожалуйста, мою переписку с tailgunner выше. Я там, как мне кажется, тему раскрыл. Если считаешь, что не раскрыл, дай знать.

//Психиатр

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

Ведь GC там был, а потом его выпилили.

ГЦ был в «самом языке» - спец-символы и т.д. А сейчас хотят сделать в виде библиотеки. По моему, разница очевидна.

А потом хотят вернуть, потому что Weak<> сочли неудобным.

Нет, не поэтому. Weak ведь никуда не денется, как и (A)RC. Это разные инструменты для разных потребностей.

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

В общем может и не хорошо. А в данном конкретном вреда не вижу. Если бы действительно выпилили RC и «заставили» использовать GC - тогда да. А так просто дополнительная возможность.

Опять же, это до сих пор остаётся на уровне обсуждений. Есть немало RFC, скажем, по низкоуровневым возможностям. Это я к тому, что запросы на фичи из разных источников поступать могут.

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

Почитай, пожалуйста, мою переписку с tailgunner выше.

Прочёл, отвечая по мере прочтения. Этот вопрос отпал, но надеюсь, что тебе найдётся что ответить на мои комментарии.

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

Раз в Rust есть аннотации и макросы, то слабые ссылки расставить можно было бы просто макросами на основе аннотаций. Даже не тревожа компилятор.

Честно говоря, не понял как должны работать такие аннотации. Если точно так же, как сейчас работает Weak? Тогда чем аннотации лучше указания типа? Или они должны делать какую-то магию?

А ГЦ нужен там, где ты не знаешь куда эти аннотации лепить.

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

Хинт: если сначала прочитать комментарии, а потом комментировать, то сбережешь свое и чужое время.

-- Непсихиатр

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

Ты, наверное, просто не в теме специфики академических языков. Это экспериментальный вещи, основная задача которых — обкатка идей. Ну и защита диссертаций по итогам.

А после этого приходят представители промышленности и пользуются (см. Cyclone и кучу рисерча по регионам).

кстати, раньше разработчики Rust считали, что у него линейная система типов

В этом деле хрен разберешься без уверенного владения матлогикой, кто там на ком стоял.

Спасибо за лекцию. Я лично из всех статей по линейным типам вынес мнемонику «value can be used at most once» - думаю, для практических целей хватит.

А разговоры про гибкость, которую приносит GC — это просто попытка представить проблему как не проблему.

Если здесь и есть проблема, то это «на линейных типах нельзя выразить всё, что нужно». Но это больше похоже на тупик в конструировании ЯП, чем на death toll для Rust.

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

Я веду к тому, что _аннотации_ можно делать только в языке, у которого в семантике прописана сборка мусора. В противном случае - только weak_ptr и K, но в Rust это можно делать уже сейчас.

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

Кстати, а как обстоят дела с вводом/выводом? :-) Такой же типобезопасный и жирный кретинизм, как с iostream? :-)

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

ГЦ был в «самом языке» - спец-символы и т.д. А сейчас хотят сделать в виде библиотеки. По моему, разница очевидна.

Да, этот момент я, бегло читая, упустил. Я был уставший. Разъяснили, спасибо :)

GC как библиотека с хуками в компилятор — это нормально.

Нет, не поэтому. Weak ведь никуда не денется, как и (A)RC. Это разные инструменты для разных потребностей.

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

А так просто дополнительная возможность.

Да, это хорошо.

Если еще что-то, то задавай, я отвечу :)

//Психиатр

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

А после этого приходят представители промышленности и пользуются

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

«value can be used at most once»

... at the same time. Т.е. гонок между потоками не будет. В этом и цель. Но есть другой подход...

Если здесь и есть проблема, то это «на линейных типах нельзя выразить всё, что нужно». Но это больше похоже на тупик в конструировании ЯП, чем на death toll для Rust.

Это не тупик, это просто аналог «no free lunch theorem» для языков программирования. Проявляется он в том, что какие-то более-менее сложные утверждения о реальных программах очень трудоемко доказать в любой логике и системе типов, особенно статически, не запуская её.

Альтернативный подход состоит в том, чтобы не делать систему типов рестриктивной и требующей полного вывода, раз такой вывод не масштабируем. Сделать её простой и пермисиивной, а контроль поведения программы возложить на эвристические анализаторы (неполный и смещенный логический вывод), как статические, так и времени выполнения. По этому пути сейчас идет С++ со своими санитайзерами.

Санитайзеры не гарантируют отсутствие ошибок, но на практике работают достаточно хорошо.

В этом смысле очень интересно следить за Rust и C++ в плане того, что у них в итоге получится :)

//Психиатр

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

В reddit

Был бы благодарен за конкретную ссылку. Признаюсь, реддит растовый читаю от случая к случаю. Правда вспоминается вот такая тема (What Rust feature would you ask for Christmas?) и там ГЦ даже не вспомнили. Зато в топе инкрементальная сборка, стабильные плагины к компилятору, всякое метапрограммирование и HKT.

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

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

Я всё-таки не понимаю, что это даст? Ну в смысле, если это будет работать точно так же, как сейчас работает Weak, то что мы выиграем? Только декларативность ради декларативности?

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

Ну в смысле, если это будет работать точно так же, как сейчас работает Weak, то что мы выиграем? Только декларативность ради декларативности?

Только удобство. Ну, не совсем только. Минус ошибки внимательности, минус ручная работа. Пусть программы пишут себя сами на сколько могут :)

//Психиатр

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

Минус ошибки внимательности, минус ручная работа.

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

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

Постой - аннотации разве не вручную расставлять придётся?

Всё верно, вручную. И их можно пропустить. Но опыт Java показывает, что аннотации подобных таких задч экономят много сил. Особенно, учитывая, что аннотации упрощают всякие gui-билдеры.

учитывая то, что он мог протухнуть

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

Поэтому и сказал, что решение не универсальное.

//Психиатр

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