костыльный assumeSafeAppend

Ну так это просто знание языка

да, но это лишний WAT

вот я тут сделал пример: https://run.dlang.io/is/t88k7F

почему эти две функции работают по разному?

первая не реаллоцирует, а вторая реаллоцирует?

и где-нибудь есть в доках описание, как именно себя ведет capacity у слайсов?

почему эти две функции работают по разному?

а вот это хороший вопрос

нужно объединить такие вещи в отдельный раздел на dusful

чтобы явно показывать "правильный путь"

когда нет ub

если правая граница слайса меньше, чем длина исходного массива, то капасити автоматически становится нулевым (отсюда и реаллокация), а если совпадает с длиной исходного массива, то капасити равно капасити исходного массива минус левая граница слайса

ub нет, все вполне определено, только слишком запутанно и сложно

тоесть это где-то определено?..

или это из ответа на форуме от разработчиков?

Это определено мною экспериментально, давно

ну и оно вполне логично

так это может быть ub

нет, я могу заранее сказать будет реаллокация или нет, достаточно точно

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

потому что используется один и тот же фронтенд

ub это же не обязательно рандом

ub - это рандом

тут скорее не описано точно

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

ага, но тут скорее UB в доках

так это и попадает под термин undefined

не определённое поведение

не определено оно в документации

значит как оно себя конкретно ведёт не является ни правильным, ни неправильным

это скорее терминологический спор

например инициализация переменных в Си

предлагаю забить, ибо неинтересно

кстати в новой редакции стандарта C++ кое что изменили

сделали как в D?)

сделали как в D?)

ни в коем случае

теперь отстутствие инициализации там называют тоже инициализацией

:D

И вроде как формально нет никакого UB :)

и что в итоге там лежит например для float и int?

nan и 0?

все как раньше

неведомо что

а

и это именно должен реализовывать компилятор?

просто раньше это называлось отсутствие инициализации, а теперь инициализация отсутствием инициализации, как-то так :D

в компиляторе ничего не поменялось в этом плане, изменился текст

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

кстати статика и глобальность в плюсах инициализируется по умолчанию нулями

можешь по D примеры вот такие выписать (как с массивом)? я потом оформлю в dusful (если конечно тебе не сложно, то было бы здово если бы ты сам их туда скинул)

это действительно может вызвать боль у людей, которые знакомятся с D

мне очень лениво, не умею и не люблю писать документацию

вообще, неестественностей в D и фобосе полным-полно

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

вот еще один прикол: https://run.dlang.io/is/y0vFGd

как определить тип элемента массива? ни в коем случае не ElementType, а typeof(T.init[0]) изврат сука

не не не, стоп, тут всё удобно

оно удобно, но не очевидно

любому новичку это покажется крайне странным

возможно

это хреново

чем меньше неочевидностей, тем лучше

автодекодирование вообще спорная штука, авторы сами сомневаются, что это верный подход

и того, на данный момент можно написать про 1. SFINAE 2. массивы и перевыделение памяти 3. аттрибуты 4. автодекодирование строк

сфинае редкий зверь

я с этой жопой столкнулся когда сериализовал в json в vibe.d

ERROR: S client not available

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

именно из-за SFINAE

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

такая же херня с opDispatch

через раз работающий inout

тут можно долго перечислять наверное

через раз работающий inout

вот это можно объяснить

всмысле я не понял

я его только в простых ситуациях пользовал

ну я пример с ходу немогу привести, просто оно перестает компиляться хотя должно. я вообще перестал им пользоваться из-за этого

имеется в виду ` class Foo { int foo() inout {...} }

многие не понимают еще разницу между immutable и const

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

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

почему? в плюсах легко

мутабельная ссылка на константный класс делается на раз

по всей видимости кто-то когда-то решил, что это может редко пригодиться и это "вошло в моду"

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

вообще-то это полезная штука для concurrency

на самом деле - ошибка дизайна как по мне

Я про языки с настоящей иммутабельностью - окамл, хаскель, кложа.. Не С++.

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

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

в дешке можно сделать мутабельную ссылку на иммутабельный массив, а вот на класс нет

и чем дешная иммутабельность не настоящая?

окамл, хаскель и кложа - это вообще ФП, они тут совсем не в тему

Там есть мутабельные ссылки.

А ненастоящая иммутабельность в С++.

в хаскеле вроде нет

https://hackage.haskell.org/package/base-4.10.1.0/docs/Control-Concurrent-MVar.html

почему в плюсах ненастоящая иммутабельность? Если объект изначально создан const, то он вполне себе настоящий иммутабельный

этож костыль