История изменений

А может вообще считать указатели структурами с единственным полем value и делать разыменовывание как ptr->value

всячески за. должно снизить порог входа

Как следует выполнять взятие адреса?

как часто это предполагается делать? Может быть тоже сделать у каждого объекта поле «адрес»? опять же должно снизить порог входа

Циклы. Классический сишный набор for-do-while с сишным же синтаксисом?

лучше перевести фокус на стримы, а в первом релизе не делать циклов вообще

array.forEach (arg: int -> { ... })

Из-за этих операций возможны всякие странные вещи типа ++i + ++i. Так ли это плохо?

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

reintepret_cast<тип>(значение)

для русского человека название неблагозвучно

я за автоматические методы типа x.toInt

можно префикс .to в названии метода сделать «специальным», и при наличии в классе метода с названием типа stringToInt подхватывать его для конвертации

или проще, сделать у всех метод .to, у которого первый аргумент - название типа. x.to(Int), а метод-конвертер ищется аналогично

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

типа:

auto x = autocast {
    1 + "x" / 163 ++ + ++ + y # черт знает что такое, скопипастил со Stackoverflow
}

А может вообще считать указатели структурами с единственным полем value и делать разыменовывание как ptr->value

всячески за. должно снизить порог входа

Как следует выполнять взятие адреса?

как часто это предполагается делать? Может быть тоже сделать у каждого объекта поле «адрес»? опять же должно снизить порог входа

Циклы. Классический сишный набор for-do-while с сишным же синтаксисом?

лучше перевести фокус на стримы, а в первом релизе не делать циклов вообще

array.forEach (arg: int -> { ... })

Из-за этих операций возможны всякие странные вещи типа ++i + ++i. Так ли это плохо?

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

reintepret_cast<тип>(значение)

для русского человека название неблагозвучно

я за автоматические методы типа x.toInt

можно префикс .to в названии метода сделать «специальным», и при наличии в классе метода с названием типа stringToInt подхватывать его для конвертации

или проще, сделать у всех метод .to, у которого первый аргумент - название типа. x.to(Int), а метод-конвертер ищется аналогично

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

типа:

auto x = autocast {
    1 + "x" / 163 ++ + ++ + y # черт знает что такое, скопипастил со Stackoverflow
}

А может вообще считать указатели структурами с единственным полем value и делать разыменовывание как ptr->value

всячески за. должно снизить порог входа

Как следует выполнять взятие адреса?

как часто это предполагается делать? Может быть тоже сделать у каждого объекта поле «адрес»? опять же должно снизить порог входа

Циклы. Классический сишный набор for-do-while с сишным же синтаксисом?

лучше перевести фокус на стримы, а в первом релизе не делать циклов вообще

array.forEach (arg: int -> { ... })

Из-за этих операций возможны всякие странные вещи типа ++i + ++i. Так ли это плохо?

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

reintepret_cast<тип>(значение)

для русского человека название неблагозвучно

я за автоматические методы типа x.toInt

можно префикс .to в названии метода сделать «специальным», и при наличии в классе метода с названием типа stringToInt подхватывать его для конвертации

или проще, сделать у всех метод .to, у которого первый аргумент - название типа. x.to(Int), а метод-конвертер ищется аналогично