@JvmInline
value class Name(val s: String)

чем не newtype?

@JvmInline
value class Name(val s: String)

Тем, что у newtype должна быть identity, просто только в компайл-тайме.

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

Нет - это не так. Это
1. Type-safe обёрка для более точного API, чтобы вместо интов передавать пиксели
2. Превью велью классов, которые не инлайн классы, а отличаются тем, что у них несколько параметров в конструкторе.

Ну вот у меня все равно в голове обертки не клеятся с value-типами. Что из этого чисто для оптимизации производительности, а что идейное?

Вот, я сформулировал: будет ли value class использоваться для чего-то кроме оптимизации производительности? Если ответить на этот вопрос, можно понять, что с этим делать дальше.

У инлайн классов есть пара ограничений, которые, в отличие от обычных классов с одним параметром в конструкторе, позволяют писать более безопасный код.
1. Нет identity - значит, можно хранить, не боясь, что значение поменяют
2. Обязательный val - по той же причине.

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

Highly likely.

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

Один из юз-кейсов - это то, чем могли бы стать data классы. У data классов есть пара проблем, которые не дают выжимать из них весь потенциал. Например, эволюция API практически невозможна с data классами. Любое изменение API ломает ABI. value классы могут, в частности, пофиксить этот баг дизайна.

Ну погоди. Дата классы в нынешнем виде вообще ортогональны. Вы разрешили там делать var - поля, и тем самым задали направление

Так data классы ложатся на язык? Если ответ "да", то велью классы тоже лягут, как более безопасный брат-близнец.

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

Отличается ли семантика велью-класса от семантики просто класса из одних валов? И опять тут имеет место смешения понятий, внутри вэлью класса может быть изменяемый объект, что приводит к тому, что решение половинчатое. Было обсуждение const классов - то есть таких, в которых все поля неизменяемы - тут все понятно, даже линзы можно добавить, чтобы народ радовался (хотя все знают, как я к ним отношусь). А тут ни то - ни се. Я, если что, не критикую, я пытаюсь ментальную модель создать.

:(

хотя мне кажется уже давно обсуждали

Это практически то же самое, что и val vs immutable - val выглядит как половинчатое решение и нужно было сразу вводить immutable, как в Расте. И у того и у этого есть юз-кейсы. Один из них, ради которого ввод immutable types (ой, простите, const classes) выглядит пальбой из пушки по воробьям я уже привёл.

Будет разрешено в 1.5.

Странная дихотомия между "можно всё" и "ничего нельзя". Половинчатое решение в данном случае имеет смысл - можно кое-что, мы предоставляем гарантии в обмен на некоторые запреты без выкручивания шкалы на 11 из 10-ти.

Я не спорю с решением. Я пытаюсь понять философию

Я уж подумал, что открыл канал с мемами