Например - невозможность создать мутабельную ссылку на иммутабельный класс (в случае PODов можно создать мутабельный указатель на иммутабельные данные) - WAT с opAssign и opEqual - невозможность не через зад создать класс на стеке.

окей

недостатки не фатальные, но решение мне представляется странным. Фактически нас принудительно заставляют использовать указатель на класс, маскируя при этом, что это указатель.

надо либо все ссылочное или все по значению.

По моему скромному, естественно.

в Лиспе не только строки. В лиспе вообще не строки, а списки. Но есть и мапы. И в смешанной семантике нет ничего природного.

Природнее СТРОКА́ ж. расположенье чего по прямой черте, сплошной ряд, линия, порядок, дорожка, полоска, что идет тесьмой, лентой, гуськом. Строка письма́, печати, ряд слов, букв, поперек страницы, а в монгольской грамоте - вдоль столбцов. Нотная строка́, пять черт, со знаками.

Природнее СТРОКА́ ж. расположенье чего по прямой черте, сплошной ряд, линия, порядок, дорожка, полоска, что идет тесьмой, лентой, гуськом. Строка письма́, печати, ряд слов, букв, поперек страницы, а в монгольской грамоте - вдоль столбцов. Нотная строка́, пять черт, со знаками.

Строка тут причем? Мы тут толкуем о природности смешанной семантики, а не строк

недостатки не фатальные, но решение мне представляется странным. Фактически нас принудительно заставляют использовать указатель на класс, маскируя при этом, что это указатель.

Нужно смотреть, что творит оптимизатор. Внутри всё может быть по-другому.

Нужно смотреть, что творит оптимизатор. Внутри всё может быть по-другому.

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

Класс, или объект?

В принципе, он может это сделать.

Класс, или объект?

объект типа класса

В принципе, он может это сделать.

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

Да ну, это все вкусовщина от однобокого опыта. Попиши полгода на окамле или другом ФЯ, там везде ссылочная семантика, и очень хорошо идет. Хотеть объекты классов на стеке - это временное заболевание, излечимое. Если нужно что-то на стеке, делай это структурой и все ок. Вон в шарпе все то же самое уже 16 лет, никто не жалуется, все ок. В жабу тоже валю-типы собираются завезти, если еще не.

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

Да ну, это все вкусовщина от однобокого опыта. Попиши полгода на окамле или другом ФЯ, там везде ссылочная семантика, и очень хорошо идет. Хотеть объекты классов на стеке - это временное заболевание, излечимое. Если нужно что-то на стеке, делай это структурой и все ок. Вон в шарпе все то же самое уже 16 лет, никто не жалуется, все ок. В жабу тоже валю-типы собираются завезти, если еще не.

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

immutable - это отдельная песня. Местами нескладная, да, но если правильно использовать, то тоже ок. Вы не должны хотеть мутабельные ссылки на иммутабельные объекты.

Там все в куче лежит (в эликсире)

Ну так кто мешает на Ди писать как на эликсире?

Сделать все иммутабельным и ссылочным

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

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

единственная фишка которая меня не устаивает в плане различик класс/структура это недетерминированность вызова деструктора для класса.

в остальном всё ок

А в эликсире не возникает таких мыслей, что аллокаций много?

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

Обычно либо мы в системном стиле пишем, там все на структурах.

Либо в стиле ООП или ФЯ, там все в куче.

А в эликсире не возникает таких мыслей, что аллокаций много?

эликсир не системный язык, я не пишу на нем, что-то высокоскоростное, у него другие фишки

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

в плюсах просто вагоны

Да ну?

Да ну?

Ага, контейнеры из буста, например

И какой там полиморфизм?

Статический полиморфизм в стиле плюсов в Ди со структурами тоже доступен.

А рантайм-полиморфизм со стеком не дружит и в плюсах.

Это прямая дорога к сегфолтам

И какой там полиморфизм?

Обычный такой полиморфизм с наследованием, например интрузивные контейнеры.

А рантайм-полиморфизм со стеком не дружит и в плюсах.

это еще почему?

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

слайсинг

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

известен, если создается на стеке

и можно передать как базовый по указателю в другие функции

эти другие ф-ии не смогут копировать объект себе на стек

эти другие ф-ии не смогут копировать объект себе на стек

а зачем им это делать? Речь о создании объекта на стеке, а не копировании его на стек.

там, где тип известен, нет рантайм-полиморфизма

если с объектом вся работа потом через ссылки, это уже ссылочная семантика по сути пошла

если с объектом вся работа потом через ссылки, это уже ссылочная семантика по сути пошла

ага, дык я не против ссылочной семантики, я против смешанной.

Так это в плюсах она смешанная получается: с одним и тем же объектом работаешь и так и так

А в Ди она не смешивается обычно: либо так, либо так

Хотя передача структур по ссылке тоже бывает, конечно

Так это в плюсах она смешанная получается: с одним и тем же объектом работаешь и так и так

в плюсах она единообразная для подов и для объектов.

а в дешке выглядит одинаково, а на самом деле нет.

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

В плюсах все на совести программиста

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

хочешь перемещай, не хочешь не перемещай

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

ну это спорный вопрос

Это вопрос типизации, насколько она строгая. Кому-то вон вообще статические типы жмут, неудобно. :)

Это вопрос типизации, насколько она строгая. Кому-то вон вообще статические типы жмут, неудобно. :)

ага, тем не менее недостатки есть, преимуществ не вижу.

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

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

Это плохо - ограничение свободы. Из за этого бага я вообще стараюсь никогда не использовать классы в дешке

В плюсах если ты используешь рантайм-полиморфизм, то тоже только по ссылке передавать можешь.

Вот это и внесли в типы.

В плюсах если ты используешь рантайм-полиморфизм, то тоже только по ссылке передавать можешь.

А если не использую полиморфизм, но использую наследование, то вполне могу передать и так и эдак

а создать на стеке полиморфный объект тоже могу легко. И передавать его по указателю.

И в Ди можешь такое сделать, наследуя структуру через alias this

И в Ди можешь такое сделать, наследуя структуру через alias this

это не наследование

это грабли почище копирования полиморфного объекта на стек

А покажи юз-кейс с наследованием и стеком

Какие-то странные проблемы

У меня за 6 лет не возникли

Если очень хочется объект класса на стеке, для того есть соответствующий аллокатор, помимо scoped

А покажи юз-кейс с наследованием и стеком

например мьютекс создать на стеке или в составе структуры, в D

а где там наследование?

Если очень хочется объект класса на стеке, для того есть соответствующий аллокатор, помимо scoped

ага, сначала сделать фигню, а потом костыли вроде Rebindable и scoped для ее обхода. Это так по-дешному.

rebindable это из другой оперы, это из серии "хочу странного"

а где там наследование?

Ну посмотри на дешный мьютекс из фобоса, что за детские вопросы

rebindable это из другой оперы, это из серии "хочу странного"

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

В ФЯ сплошь и рядом мутабельные "ссылки" на иммутабельные обьекты

В ФЯ свои аналоги rebindable - всякие IORef

Простые ссылки там тоже иммутабельные

А в чем проблема мьютекс в составе структуры сделать? Что надо в деструкторе упоминать?

Простые ссылки там тоже иммутабельные

не везде, в эликсире нет

А в чем проблема мьютекс в составе структуры сделать? Что надо в деструкторе упоминать?

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

(про эликсир) по-моему, мы это уже обсуждали. переопределение переменной это не присваивание

(про эликсир) по-моему, мы это уже обсуждали. переопределение переменной это не присваивание

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

нет, это не мутабельная ссылка, совсем

там даже тип может меняться

это просто совпадение имен

мутабельная ссылка это аналог биндинга обьектов в ФЯ.

нет

да

нет

да

:)

:)

let a = "aaa" in let pair = (a,a) in let a = "bbb" in fst pair если бы "a" была мутальной ссылкой, мы бы тут получили "bbb", но получим старое значение - "ааа"

вот и вся разница

это новая переменная каждый раз

Такие "мутабельные ссылки" у тебя и Ди есть, просто называй ее каждый раз по-разному. :)

я просто реально сталкивался. у меня есть некий стейт в котором я храню иммутабельный объект. Как это сделать? Стейт это структура или класс.