C таким же успехом можно декомпилировать в C# код с async-await'ами, посмотреть на этот жуткий код (даже без всяких «закорючек») конечного автомата сгенерированный компилятором, и так же само продвигать всю это ахинею про «А что так нельзя написать что ли? Вполне валидный код на C#».
Это не просто «идеологически красиво», а это те инварианты, которые можно выразить в типа, и дальше переложить их проверку на компилятор, вместо того чтобы держать все время в голове и дебажить связанные с ними ошибки. Вы ведь не будете спорить что компайлтайм ошибки находятся и соотвественно фиксятся гораздо быстрее, чем рантайм ошибки?
Синтаксис будто никогда не проектировался, а формировался по типу «о, давайте добавим того, этого». У Go в основе синтаксиса лежит цельная идеология. Да, у него есть недостатки, но он хотя бы создаётся с последовательной философией. У Python тоже самое, Гвидо имеет фантастическую интуицию что стоит добавлять а что нет.
Т. е. вы пока еще не понимаете идеологии раста. Видимо, вам стоит просто получше разобраться с языком. Могу на этот счет посоветовать rust book.
Это уже какой-то маразм. Вы пытаетесь поставить в виду языку наличие удобной функции документирования в языке и то что программисты этой функцией пользуются правильно, приводя примеры использования кода и поясняя граничные случаи.
Вообще, вопросы, связанные с Unsoundness для Pin действительно не простые. Если вы не согласны с фиксом, то думаю, гораздо продуктивнее будет написать сразу в указанную вами issue.
relies on the implementations of Deref and DerefMut not to move out of their self parameter, and only ever to return a pointer to pinned data when they are called on a pinned pointer.
2. Pin через unsafe отдает сырой указатель (ссылку) другому потоку или кому угодно, что тот с ним работал. Но ОВ второго потока ни сном ни духом про соперника.
Ну вот опять вы придумываете.
Pin, как и другие смарт-поинтеры раста, не нарушает гарантии, которые предоставляет раст для своего safe подмножества и не передает никакие указатели в другие потоки сам по себе.
Вы что-то сами себе придумали (кстати, говоря уже далеко не первый раз). Pin там как раз и есть для того чтобы через типы запретить некорректные операции по работе с памятью во время await'ов.
Я думаю, что khim намикал на Соответствие Карри — Ховарда. Благодаря, которому можно как бы программируя доказывать истинность логических высказываний, что уже довольно близко к научной деятельности.
А, может быть, она таковой является только потому, что мы когда-то изучили смысл слов на нашем разговорном языке?) По названию функции предполагаем что она делает. Сложность теперь там..)
Конечно же, нет. Вся сложность реализации заключается в теле функции. А функция выступает как средство абстрагирования. Т. е. нам за частую не нужно знать детали реализации функции для ее использования. А то что нужно знать (ограничения для правильного использования) стараются вынести в сигнатуру функции. И в большинстве новых языков вы эти ограничения тем или иным образом можете выразить. Как приятный бонус к этому идет проверка корректности использования функции компилятором и оптимизации.
Более того современные языки приходят к похожему базовому набору выразительных стредств. Видимо где-то там находится минимальный набор языковых конструкций, необходимый для выражения довольно широкого набора ограничений (но это так, к слову).
Например:
extension Sequence where Element: Comparable {
public func sorted() -> [Element]
}
Все три языка явно указывают и проверяют, что для элементов последовательности должна быть реализована функция сравнения, иначе не получится их отсортировать.
Вроде как нашли костыль для сложности — функция. Каждая функция делает свое дело (API вызов) и является объектом познания без изучения кода.
Таким образом сложность из кода (уровень программиста) вытекает выше на уровень бизнес-аналитика, который оперирует теми самыми API вызовами.
Мне было интересно «вдруг умные мужики придумали рабочий вариант внедрения borrow checker'a». Но пока что для меня оба эти подхода выглядят очень сомнительно. Не верится мне что они будут работать, что ими будут пользоваться.
А мне кажется, вы пытаетесь сделать хорошую мину при плохой игре, ничего не говоря по сути.
В D он включает DFA для конкретных функций. А в C++ пошли другим путем — DFA для всего включается при ключе компиляции.
Не особо важно на каком уровне включается механизм проверки. Важно как осущесвтляется переход от safe части к unsafe и обратно. И тут, по сути, я вижу только 2 подхода:
1. Перенос классического статического анализатора в компилятор. Который, легко заиспользовать. но он ничего не гарантирует
2. Разметка монструозными атрибутами кода (уж лучше бы новый синтаксис предлагали) с написанием оберток существующих библиотек (в том числе и стандартной библиотеке)
Не такое уж и громоздкое описание подходов получилось.
Приводить в пример D вообще, странно. Т. к. переход к borrow checker'у c языка с GC совсем не тоже самое что переход с языка с ручным управлением памятью.
@ live — это всего лишь атрибут, а механизм атрибутов в С++ тоже есть, даже стандартизовали.
Получается атрибут live, по сути, берет и превращает текущий C++ в другой язык с другой семантикой (аля С++ SAFE)
И что это меняет относительно моей изначальной посылки? Текущий код и код существующих С++ библиотек не станет автоматически совместим с семантикой нового языка, и нужна будет обернутая/новая стандартная библиотека и враперы для текущих библиотек нужно будет писать или сами библиотеки переписывать.
Про «ахах конечно есть» это был намёк про Раст, библиотеки которого сплошь ансейф, если Вы не поняли.
Не стоит преувеличивать. Как правило это либо биндинги к текущим плюсовым библиотекам (но там особо выбора нет как и скорее всего у условного C++ SAFE), либо unsafe сильно локализован, как правило отдельными небольшими функциями.
Я думаю, acmnu как раз скажет вам спасибо, если вы ему подскажите в какой книге хорошо описано что и как сейчас стоит использовать, а чего стоит избегать.
Т. е. вы пока еще не понимаете идеологии раста. Видимо, вам стоит просто получше разобраться с языком. Могу на этот счет посоветовать rust book.
Попытаться доказать что это «что-то» действительно невозможно и прийти к противоречию.
Как-то так
Вообще, вопросы, связанные с Unsoundness для Pin действительно не простые. Если вы не согласны с фиксом, то думаю, гораздо продуктивнее будет написать сразу в указанную вами issue.
Pin обходит правила владения не больше чем Box. Вы же не будите, что из-за Box в расте возникают датарейсы?
Ну вот опять вы придумываете.
Pin, как и другие смарт-поинтеры раста, не нарушает гарантии, которые предоставляет раст для своего safe подмножества и не передает никакие указатели в другие потоки сам по себе.
Конечно же, нет. Вся сложность реализации заключается в теле функции. А функция выступает как средство абстрагирования. Т. е. нам за частую не нужно знать детали реализации функции для ее использования. А то что нужно знать (ограничения для правильного использования) стараются вынести в сигнатуру функции. И в большинстве новых языков вы эти ограничения тем или иным образом можете выразить. Как приятный бонус к этому идет проверка корректности использования функции компилятором и оптимизации.
Более того современные языки приходят к похожему базовому набору выразительных стредств. Видимо где-то там находится минимальный набор языковых конструкций, необходимый для выражения довольно широкого набора ограничений (но это так, к слову).
Например:
Kotlin
Rust
Swift (docs github)
Все три языка явно указывают и проверяют, что для элементов последовательности должна быть реализована функция сравнения, иначе не получится их отсортировать.
Вроде как нашли костыль для сложности — функция. Каждая функция делает свое дело (API вызов) и является объектом познания без изучения кода.
Таким образом сложность из кода (уровень программиста) вытекает выше на уровень бизнес-аналитика, который оперирует теми самыми API вызовами.
И не благодарите ;-)
Не особо важно на каком уровне включается механизм проверки. Важно как осущесвтляется переход от safe части к unsafe и обратно. И тут, по сути, я вижу только 2 подхода:
1. Перенос классического статического анализатора в компилятор. Который, легко заиспользовать. но он ничего не гарантирует
2. Разметка монструозными атрибутами кода (уж лучше бы новый синтаксис предлагали) с написанием оберток существующих библиотек (в том числе и стандартной библиотеке)
Не такое уж и громоздкое описание подходов получилось.
Приводить в пример D вообще, странно. Т. к. переход к borrow checker'у c языка с GC совсем не тоже самое что переход с языка с ручным управлением памятью.
Получается атрибут live, по сути, берет и превращает текущий C++ в другой язык с другой семантикой (аля С++ SAFE)
И что это меняет относительно моей изначальной посылки? Текущий код и код существующих С++ библиотек не станет автоматически совместим с семантикой нового языка, и нужна будет обернутая/новая стандартная библиотека и враперы для текущих библиотек нужно будет писать или сами библиотеки переписывать.
Не стоит преувеличивать. Как правило это либо биндинги к текущим плюсовым библиотекам (но там особо выбора нет как и скорее всего у условного C++ SAFE), либо unsafe сильно локализован, как правило отдельными небольшими функциями.
Я думаю, acmnu как раз скажет вам спасибо, если вы ему подскажите в какой книге хорошо описано что и как сейчас стоит использовать, а чего стоит избегать.