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

Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?

Константность:

const / mutable

Асинхронность:

sync / async

Виртуальность:

virtual / direct

Передача:

ref / value

Видимость:

public / private / ...

Из моего опыта по умолчанию должно быть примерно так:

Константность: всё константно, если надо иначе пиши mutable (конверт из константной ссылки с copy-on-write)
Асинхронность: всё асинхронно, хочешь синхронный вызов добавь sync
Виртуальность: всё виртуально, хочешь прямой вызов объяви снаружи/статический
Передача: всё по ссылке, для копии нужно указать value на типе или на переменной.
Видимость: всё публичное, если надо спрятать добавляешь private и ко.

Какой язык мне посоветуете?

Здравствуйте, Caracrist, Вы писали:

C>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?

C>Константность:
C>const / mutable

const. Параметры функций не могут быть mutable вообще. А скорей я бы отказался от отдельного ключевого слова для объявления переменной, переменная объявляется сама при первом упоминании.

C>Асинхронность:
C>sync / async

В JS сделано нормально, ничего бы не стал менять. Если язык не низкоуровневый, скорей всего выбрал бы вариант с зелеными потоками и отказ от async-конструкций в принципе.

C>Виртуальность:
C>virtual / direct

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

C>Передача:
C>ref / value

value, ref в языке не нужен.

C>Видимость:
C>public / private / ...

В интерфейсах всё public, в классах всё private (точней package-private), менять это нельзя.

Здравствуйте, vsb, Вы писали:

vsb>В интерфейсах всё public, в классах всё private, менять это нельзя.

Это интересный момент. Тоесть, поля только private и доступ снаружи только через интерфейс.
А что, мне нравится

Здравствуйте, Caracrist, Вы писали:

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

C>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?

C>Константность:
C>

C>const / mutable
C>

C>Асинхронность:
C>

C>sync / async
C>

C>Виртуальность:
C>

C>virtual / direct
C>

C>Передача:
C>

C>ref / value
C>

C>Видимость:
C>

C>public / private / ...
C>

Однобоко рассматривать всё это с позиций безопасности. virtual влечёт оверхед, пусть и небольшой. ref / value зависит от наличия адресной арифметики. И так далее. Пожалуй, только const по умолчания хорош для всех типов языков.

Здравствуйте, vsb, Вы писали:

C>>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?

C>>Константность:
C>>const / mutable

vsb>const. Параметры функций не могут быть mutable вообще.

Почему? Я не могу например счётчик попыток принять и уменьшать?
(Я понимаю, что скопировать нет проблем, но всё же)

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

Ты серьёзно??
Во всём коде функции используется kptm2, в одном месте kmpt2. Удачи в поиске. Особенно в конце спринта с рычащим тимлидом.
Блин, как я когда-то с этим с Фортране натрахался... (старом, конечно, в новых `implicit none` и вопрос решён). Сейчас за такие идеи только ломом по кумполу.

Здравствуйте, netch80, Вы писали:

vsb>> А скорей я бы отказался от отдельного ключевого слова для объявления переменной, переменная объявляется сама при первом упоминании.
N>Ты серьёзно??

Я то же самое хотел спросить, но решил, что чего-то недопонял

Здравствуйте, Caracrist, Вы писали:


C>Видимость: всё публичное, если надо спрятать добавляешь private и ко.

хмм, почему? По-моему наоборот по-умолчанию все должно быть спрятано. Заставляет задумываться о том, что видно снаружи.

Здравствуйте, Caracrist, Вы писали:

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

C>Однако, иногда нужны были бы модификаторы. Вопрос такой, какое поведение вы выбрали по умолчанию, а какое с модификатором из следующих категорий?

C>Константность:
C>

C>const / mutable
C>

В идеале — вообще просто разные слова (let/var, например). Вот для чего-то вроде параметров функций — или те же слова, или таки mutable.

C>Асинхронность:
C>

C>sync / async
C>

Крайне сложно выбрать, зависит от домена.

C>Виртуальность:
C>

C>virtual / direct
C>

Direct. Ибо произвольное перекрытие сверху... ну может для тестовых сборок (с отдельным режимом компиляции), но не для всех. Тут лучше какой-то "перекрывать разрешается только таким-то наследникам" (или с конкретными грейдерами).

C>Передача:
C>

C>ref / value
C>

Учитывая, что в языках типа Java/C#/Python/etc. реально происходит передача _ссылки_ _по значению_, или вопрос некорректный, или надо его расширить. Чистое по ссылке — это, простите, старый Фортран, где сказав call foo(5) можно было получить, что 5 в памяти стало 6 для всех участников, потому что область константы была модифицирована
А вот для объектов, если не введена явная политика тотальной иммутабельности, передача ссылки по значению это таки нормальный вариант.

C>Видимость:
C>

C>public / private / ...
C>

Умолчание — [обновлено] лучше всего package-internal (если есть пакеты), за ним по полезности private. Только так. Легче потом отдельные элементы "расшарить", чем бороться с тем, что тебя поюзали и без согласования с 20 соседними департаментами ты это не ограничишь.

C>Из моего опыта по умолчанию должно быть примерно так:

C>

C>Константность: всё константно, если надо иначе пиши mutable (конверт из константной ссылки с copy-on-write)
C>Асинхронность: всё асинхронно, хочешь синхронный вызов добавь sync
C>Виртуальность: всё виртуально, хочешь прямой вызов объяви снаружи/статический
C>Передача: всё по ссылке, для копии нужно указать value на типе или на переменной.
C>Видимость: всё публичное, если надо спрятать добавляешь private и ко.
C>

Опыт сильно напоминает улучшенный JS. Это всё-таки перекос в одну конкретную сторону.

C>

Какой язык мне посоветуете?

C>

Тот, что подходит под твой домен задач.

Вообще подобный опросник в варианте скрестили ужа с ежом, то есть C с JS и накрыли хаскелем, мягко говоря, смущает

Здравствуйте, netch80, Вы писали:

vsb>>const. Параметры функций не могут быть mutable вообще.

N>Почему? Я не могу например счётчик попыток принять и уменьшать?
N>(Я понимаю, что скопировать нет проблем, но всё же)

Потому, что это редкий юз-кейс и путает. К примеру в одном из самых популярных codestyle для JS запрещается менять параметры. Фич должно быть как можно меньше. Если это приводит к тому, что в 1% функций ты создашь лишнюю локальную переменную — ну значит так тому и быть. Зато явно будет видно, что ты её создал, она мутабельная и можно отследить её изменения. А с параметрами можно не отслеживать и даже не смотреть на них, ты в 100% случаев знаешь, что они не меняются.

N>Ты серьёзно??

Да.

N>Во всём коде функции используется kptm2, в одном месте kmpt2. Удачи в поиске. Особенно в конце спринта с рычащим тимлидом.

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

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

Здравствуйте, Нomunculus, Вы писали:

Н>хмм, почему? По-моему наоборот по-умолчанию все должно быть спрятано. Заставляет задумываться о том, что видно снаружи.

по-моему, это надуманное ограничение. В большинстве случаев нужно именно public. Прятать нужно очень редко, когда изменение одного поля меняет другие (или тянет за собой побочку).
Вспоминаю свой опыт на java, когда постоянно промахивался и писал puvlic вместо public. Раздражало. Сейчас пишу на С++ и использую struct. Забыл когда писал public вообще.

Здравствуйте, sergii.p, Вы писали:

SP>по-моему, это надуманное ограничение.

Нет, это ограничение, призванное избавить от лишних ошибок.
Простой пример — член класса типа int. Думаешь это нормально что все подряд смогут его менять, а сам объект класса не будет об этом знать? Ну, это может привести к печальным результатам.

Здравствуйте, Нomunculus, Вы писали:

SP>>по-моему, это надуманное ограничение.

Н>Нет, это ограничение, призванное избавить от лишних ошибок.
Н>Простой пример — член класса типа int. Думаешь это нормально что все подряд смогут его менять, а сам объект класса не будет об этом знать? Ну, это может привести к печальным результатам.

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

Здравствуйте, Нomunculus, Вы писали:

Н>Здравствуйте, sergii.p, Вы писали:

SP>>по-моему, это надуманное ограничение.

Н>Нет, это ограничение, призванное избавить от лишних ошибок.
Н>Простой пример — член класса типа int. Думаешь это нормально что все подряд смогут его менять, а сам объект класса не будет об этом знать?

к печальным последствиям приводит изменение как таковое. А будет setMember, или просто member дела не меняет. Это конечно справедливо, когда все поля независимы от других и изменением поля нельзя сломать внутреннее состояние. Но это 95% случаев.

Здравствуйте, vsb, Вы писали:

vsb>>>const. Параметры функций не могут быть mutable вообще.

N>>Почему? Я не могу например счётчик попыток принять и уменьшать?
N>>(Я понимаю, что скопировать нет проблем, но всё же)

vsb>Потому, что это редкий юз-кейс и путает. К примеру в одном из самых популярных codestyle для JS запрещается менять параметры. Фич должно быть как можно меньше. Если это приводит к тому, что в 1% функций ты создашь лишнюю локальную переменную — ну значит так тому и быть. Зато явно будет видно, что ты её создал, она мутабельная и можно отследить её изменения. А с параметрами можно не отслеживать и даже не смотреть на них, ты в 100% случаев знаешь, что они не меняются.

Ну вот почему-то ты сделал такое разделение. А другой скажет, что параметр функции — такая же локальная переменная, но автоматически присвоившая значение на входе. И я не вижу, чем один вариант существенно обоснованнее другого. Мне тоже _чуть-чуть_ было бы удобнее видеть, что параметры неизменяемы, но я не могу найти этому обоснования и не вижу силы за твоим обоснованием.

N>>Во всём коде функции используется kptm2, в одном месте kmpt2. Удачи в поиске. Особенно в конце спринта с рычащим тимлидом.

vsb>Если это неизменяемая переменная, то второе место не скомпилируется.

Кто из этих двоих переменных "это"?

vsb> Если это изменяемая, такой сюжет может пройти (хотя проверки вроде предупреждений о том, что значение присвоено, но не использовано, могут помочь), но изменяемых переменных априори должно быть слишком мало, чтобы это создавало проблемы на практике. Если у тебя это составляет проблему, вкупе с работающими юнит-тестами, ты что-то сильно не так делаешь.

"Что-то сильно не так делаешь" это слишком абстрактный аргумент, чтобы иметь хоть какую-то силу. Нужно, чтобы ситуации не происходило вообще, или в крайне малом количестве случаев.
А учитывая, что объявление переменной ещё и (обычно) должно задавать её тип (кроме случаев, когда ты явно разрешил компилятору автовывод типа) — то за аргументы за автосоздание переменной уходят в область бесконечно малых.

vsb>Я это не упоминал, но подразумевается, что во вложенном блоке нельзя объявить локальную переменную с тем же именем, что и снаружи. Как раз для того, чтобы исключить такую проблему.

По-моему, это не сильно связанные вещи.

Здравствуйте, netch80, Вы писали:

vsb>>Потому, что это редкий юз-кейс и путает. К примеру в одном из самых популярных codestyle для JS запрещается менять параметры. Фич должно быть как можно меньше. Если это приводит к тому, что в 1% функций ты создашь лишнюю локальную переменную — ну значит так тому и быть. Зато явно будет видно, что ты её создал, она мутабельная и можно отследить её изменения. А с параметрами можно не отслеживать и даже не смотреть на них, ты в 100% случаев знаешь, что они не меняются.

N>Ну вот почему-то ты сделал такое разделение. А другой скажет, что параметр функции — такая же локальная переменная, но автоматически присвоившая значение на входе. И я не вижу, чем один вариант существенно обоснованнее другого. Мне тоже _чуть-чуть_ было бы удобнее видеть, что параметры неизменяемы, но я не могу найти этому обоснования и не вижу силы за твоим обоснованием.

Все мои предпочтения это исключительно opinionated, как говорится. Я кодирую в своих предпочтениях настолько строгий стиль кодирования, насколько это разумно в рамках синтаксиса языка. Конечно нет ничего сакрального в неизменяемых параметрах. Просто мне так кажется правильней. Изменяемые переменные должны быть нужны редко. Но не настолько редко, чтобы от них отказываться, иначе это уже что-то вроде хаскеля со своей историей, как говорится. mutable параметры нужны ещё реже и от них уже отказаться можно, т.к. всё же это семантически немного другая сущность и то, что они в большинстве языков программирования тождественны локальным переменным, это просто такая мода. Никаких проблем такой отказ не несёт, просто человек объявит лишнюю переменную. Может даже у этой лишней переменной будет более удачное имя.

N>>>Во всём коде функции используется kptm2, в одном месте kmpt2. Удачи в поиске. Особенно в конце спринта с рычащим тимлидом.

vsb>>Если это неизменяемая переменная, то второе место не скомпилируется.

N>Кто из этих двоих переменных "это"?

Немного не то сказал. Мой поинт в том, что неизменяемой переменной ты не будешь на ровном месте присваивать новое значение. Т.е. ты не будешь писать код kptm2 = 1; ...; kmpt2 = 2; print(kmpt2). Ты вернёшься на место объявления kptm2 и напишешь mutable kptm2 = 1; ...; kmpt2 = 2; print(kmpt2) к примеру. И вот этот пример уже выдаст ошибку — mutable переменная не была изменена.

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

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

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

N>"Что-то сильно не так делаешь" это слишком абстрактный аргумент, чтобы иметь хоть какую-то силу. Нужно, чтобы ситуации не происходило вообще, или в крайне малом количестве случаев.
N>А учитывая, что объявление переменной ещё и (обычно) должно задавать её тип (кроме случаев, когда ты явно разрешил компилятору автовывод типа) — то за аргументы за автосоздание переменной уходят в область бесконечно малых.

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

Здравствуйте, sergii.p, Вы писали:

SP>>>по-моему, это надуманное ограничение.

Н>>Нет, это ограничение, призванное избавить от лишних ошибок.
Н>>Простой пример — член класса типа int. Думаешь это нормально что все подряд смогут его менять, а сам объект класса не будет об этом знать?

SP>к печальным последствиям приводит изменение как таковое. А будет setMember, или просто member дела не меняет.

1. Даже если ограничиться твоим примером — меняет хотя бы потому, что если setMember(), ты его одного можешь зарезать или вставить в него отладочную печать, поставить на нём бряк, переделать в установку нескольких других полей, и всё такое. А если прямое присвоение в member, то сначала тебе надо все такие прямые присвоения переделать в вызов сеттера, и только потом разбираться, что же из них недопустимое. (Property стиля C# решают это же косвенно, но ломая ABI для тех модулей, что уже скомпилировались с прямым доступом. Или там это обошли?)

2. А ещё важнее то, что если у тебя в публичном доступе есть только методы, сохраняющие инварианты, а прямая установка поля этот инвариант может сломать, то выставление в public только беспроблемных методов реально повышает защиту.

Да, это азы, и я надеюсь, что объяснять их не надо было, но это необходимо как вводная к тому, что чем меньше автоматического public, тем лучше для сохранности.

Кстати, я таки думаю, что самый правильный стиль из этих таки не в C++ private/protected/public, а в Java/C#, где умолчанием является package-internal. При нём и посторонние не пролезут, и круг своих аккуратно ограничен, но достаточно широк, чтобы не кидаться friendʼами попусту.

SP>Это конечно справедливо, когда все поля независимы от других и изменением поля нельзя сломать внутреннее состояние. Но это 95% случаев.

Где 95% случаев и почему?
Вокруг меня всё-таки 95% случаев это когда класс имеет своё состояние, которое надо защищать даже от случайных диверсий поломки целостности.

Здравствуйте, vsb, Вы писали:

N>>Ну вот почему-то ты сделал такое разделение. А другой скажет, что параметр функции — такая же локальная переменная, но автоматически присвоившая значение на входе. И я не вижу, чем один вариант существенно обоснованнее другого. Мне тоже _чуть-чуть_ было бы удобнее видеть, что параметры неизменяемы, но я не могу найти этому обоснования и не вижу силы за твоим обоснованием.

vsb>Все мои предпочтения это исключительно opinionated, как говорится. Я кодирую в своих предпочтениях настолько строгий стиль кодирования, насколько это разумно в рамках синтаксиса языка. Конечно нет ничего сакрального в неизменяемых параметрах. Просто мне так кажется правильней. Изменяемые переменные должны быть нужны редко. Но не настолько редко, чтобы от них отказываться, иначе это уже что-то вроде хаскеля со своей историей, как говорится.

Ну вообще всё семейство ФП. Я на Эрланге много писал. Неизменяемые переменные его стиля это, конечно, красиво. Но иногда они превращаются в жуткий геморрой. То надо передавать 50 изменяемых значений в функцию, рекурсивно... — приходится передавать одну большую мапу со значениями. То простейший цикл уже не напишешь без рекурсии. В тяжёлых случаях коллеги вообще переходили на словарь процесса (в его контексте это грубость, как в C++ кастовать указатели между несвязанными классами и ходить по смещению от них).
Вот честно, больше не хочу такого. Тут согласен, что их надо оставить.

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

vsb> mutable параметры нужны ещё реже и от них уже отказаться можно, т.к. всё же это семантически немного другая сущность

Ну вот насколько это "немного", достаточно ли его для другой политики — ХЗ.

vsb> и то, что они в большинстве языков программирования тождественны локальным переменным, это просто такая мода. Никаких проблем такой отказ не несёт, просто человек объявит лишнюю переменную. Может даже у этой лишней переменной будет более удачное имя.

Про имена это к Swift — там у параметров разделяются внутренние и внешние имена — и это правильно.

N>>>>Во всём коде функции используется kptm2, в одном месте kmpt2. Удачи в поиске. Особенно в конце спринта с рычащим тимлидом.

vsb>>>Если это неизменяемая переменная, то второе место не скомпилируется.

N>>Кто из этих двоих переменных "это"?

vsb>Немного не то сказал. Мой поинт в том, что неизменяемой переменной ты не будешь на ровном месте присваивать новое значение. Т.е. ты не будешь писать код kptm2 = 1; ...; kmpt2 = 2; print(kmpt2). Ты вернёшься на место объявления kptm2 и напишешь mutable kptm2 = 1; ...; kmpt2 = 2; print(kmpt2) к примеру. И вот этот пример уже выдаст ошибку — mutable переменная не была изменена.

Эээ.
1. А с чего бы это сразу объявлять ошибкой? Ну mutable, ну не изменена.
(На самом деле тут ещё один вопрос, конечно. Имеет смысл по умолчанию делать, что ситуации типа "присвоенное значение не используется" создают ошибки. Как минимум в release-сборке, если использовать это деление. Но есть же автоматическая генерация кода. Надо иметь возможность контекстно-локально отключать такие ошибки.)
2. Но представь себе, что kmpt2 написано дважды вместо kptm2 в разных местах. Это тоже вероятно. Всё, твой контроль по принципу единичности — уже не сработает. Контроль по неиспользуемости присвоенного значения — может сработать, а может и нет — в зависимости от интеллекта компилятора.

Ну и см. ниже про типы.

Опциональную политику такого объявления по первому присвоению я бы понял. Тотальную — нет. По умолчанию — тоже нет. Даже для Хаскеля

vsb>Если эта переменная изначально была mutable и ты опечатался в низу функции и случайно завёл новую переменную, тут ничего не сделать, будет баг, да.

Ну вот да — контроль тут будет, мягко говоря, слабым.

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

Надо смотреть на практику Питона, где эта диверсия по умолчанию.

vsb>Я считаю, что есть большая ценность в том, чтобы убрать визуальный шум от объявления неизменяемой переменной, т.к. этот шум читателю кода ничего не даёт.

Хм.
Раньше я был категорическим сторонником стиля "чем меньше букв, тем лучше". А потом начал активно смещаться в сторону того, что некоторая избыточность крайне полезна. Не, например, begin-end вместо {}, это уже перебор, а, например, "var x: int", а не "var x int", как в Go. Обязательны слова типа var, function (даже если сократить до fn, как сейчас модно), и вообще стиль объявлений Pascal / Go / (самый новый) C++ с auto и ->, чтобы не плодить Most Vexing Parse. Ну и прочее. Набирать не сильно больше, а пользы — вагоны.
Так и тут — если ты напишешь "let kptm2 = foo()", или "kptm2 := foo()", как в Go с его присвоением-с-декларацией, а не "kptm2 = foo()", это будет совершенно минимальная добавка, зато исключит массу проблем.

N>>"Что-то сильно не так делаешь" это слишком абстрактный аргумент, чтобы иметь хоть какую-то силу. Нужно, чтобы ситуации не происходило вообще, или в крайне малом количестве случаев.
N>>А учитывая, что объявление переменной ещё и (обычно) должно задавать её тип (кроме случаев, когда ты явно разрешил компилятору автовывод типа) — то за аргументы за автосоздание переменной уходят в область бесконечно малых.

vsb>Автовывод типа это уже давно стандарт де-факто почти во всех языках и подразумевается сам собой.

Да вот не совсем. Ты смешиваешь два автовывода — автовывод по инициализации и автовывод по всему использованию.
Первый — удел процедурных языков. Второй — группы *ML/Haskell/etc.

Но это уклонение от вопроса, потому что:

vsb>Все типы локальных переменных выводятся и это не опционально.

Ну да, ещё скажи, что ты не можешь сказать "int x" для локальной переменной, только "var x"
Непонятно, что ты имел в виду на самом деле, но сказано безнадёжно коряво. Перефразируй.

Здравствуйте, netch80, Вы писали:

vsb>>Немного не то сказал. Мой поинт в том, что неизменяемой переменной ты не будешь на ровном месте присваивать новое значение. Т.е. ты не будешь писать код kptm2 = 1; ...; kmpt2 = 2; print(kmpt2). Ты вернёшься на место объявления kptm2 и напишешь mutable kptm2 = 1; ...; kmpt2 = 2; print(kmpt2) к примеру. И вот этот пример уже выдаст ошибку — mutable переменная не была изменена.

N>Эээ.
N>1. А с чего бы это сразу объявлять ошибкой? Ну mutable, ну не изменена.
N>(На самом деле тут ещё один вопрос, конечно. Имеет смысл по умолчанию делать, что ситуации типа "присвоенное значение не используется" создают ошибки. Как минимум в release-сборке, если использовать это деление. Но есть же автоматическая генерация кода. Надо иметь возможность контекстно-локально отключать такие ошибки.)

Можно делить на ошибки и предупреждения, но в релизном коде не должно быть ни тех, ни других. Хотя я бы вообще предложил кардинальный подход — не делить на ошибки и предупреждения, а генерировать в отладочном режиме бинарник, даже если встречаются ошибки, которые можно локализовать. Я давным давно писал на жава в эклипсе, вот там такая фича была. И это было очень удобно. Не дописал функцию, и ладно. Если туда управление придёт, то вместо недокомпилированного кода вылетит ошибка. А так — какой-то кусок кода недописан, а ты тестируешь другой кусок и тебе на первый кусок пофиг, пускай генерирует, что может. Есть исключения вроде несбалансированных фигурных скобок, но обычно ошибку локализовать можно. А если немножко включить эвристики и проанализировать отступы, можно и про скобки подумать.

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

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

N>Надо смотреть на практику Питона, где эта диверсия по умолчанию.

Вот, кстати, да. Я на питоне не то, чтобы много писал, но немного писал. И конкретно эта фича мне проблем кажется не доставляла.

N>Так и тут — если ты напишешь "let kptm2 = foo()", или "kptm2 := foo()", как в Go с его присвоением-с-декларацией, а не "kptm2 = foo()", это будет совершенно минимальная добавка, зато исключит массу проблем.

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

vsb>>Автовывод типа это уже давно стандарт де-факто почти во всех языках и подразумевается сам собой.

N>Да вот не совсем. Ты смешиваешь два автовывода — автовывод по инициализации и автовывод по всему использованию.
N>Первый — удел процедурных языков. Второй — группы *ML/Haskell/etc.

Я про первый. Автовывод типов для функций — вопрос сложный. С одной стороны для всяких лямбд он нужен по-любому, с другой стороны для "настоящих" функций типы должны быть фиксированы, когда я хаскель изучал, даже там рекомендовалось сигнатуры прописывать вручную.

vsb>>Все типы локальных переменных выводятся и это не опционально.

N>Ну да, ещё скажи, что ты не можешь сказать "int x" для локальной переменной, только "var x"
N>Непонятно, что ты имел в виду на самом деле, но сказано безнадёжно коряво. Перефразируй.

Не очень понял, что не понятно. У нас ведь в гипотетическом языке нет ни var ни int. У нас есть только x = 1 или x = get_int_value(). Иными словами типы всех локальных переменных выводятся автоматически и отказаться от этого нельзя. Максимум — добавить каст в инициализирующее выражение, чтобы привести его к нужному типу.

Здравствуйте, netch80, Вы писали:

N>Где 95% случаев и почему?

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

Здравствуйте, sergii.p, Вы писали:

N>>Где 95% случаев и почему?
SP>потому что тип-произведение предназначен для хранения независимо изменямых полей по определению. Если это не так, значит мы спроектировали тип плохо, или у нас не хватает мощности языка.
SP>Собственно ущербность идеи set методов проявляется уже в том, что каждый может вернуть ошибку инварианта. Люди воспитанные на исключениях скажут, что это не проблема. Но не все такие оптимисты...
SP>Решение мне видится в неизменямости объектов. Но признаю, что это не для всех.

У нас, похоже, слишком разный опыт, чтобы говорить об одном и том же.

Вот, например, задача в текущем проекте. Есть набор наблюдаемых ячеек, с которых надо снимать характеристики и трассировать изменения состояния.
И есть особенность состояния "вот сейчас мы готовы отправлять что-то или нет", и где тот, кому надо отправлять.
Я могу вызвать SetCellTrace(int cell_index, bool onoff), который не может дать сам по себе никакой ошибки инварианта, но если хоть у одной ячейки было true, поднимается соединение с получателем. И могу вызвать SetCollectorAddress(address_t address), который может вызвать дисконнект (если адрес пустой), реконнект, или ничего, если сбор не был включен.
То есть эти два сеттера это не просто сеттеры, они вызывают самостоятельные действия получателя.
А ещё рядом есть SetTraceReference(int cell_index, long reference), который действительно тупо сеттер, но когда вызывается отсылка данных, этот reference извлекается и участвует в формировании данных в отправляемой нотификации. А ещё есть аналогичное для trace level, которое управляет объёмом отправляемого.
И что из них собственно "тип-произведение" в твоём смысле, если у каждого поля данных есть побочный эффект?
Только не надо говорить, что всё это надо перепроектировать с нуля и сделать соответствие типам-суммам, типам-произведениям, и всему такому. Неподъёмно и, скорее всего, ненужно.