Исправление
stevejobs,
(текущая версия)
:
А может вообще считать указатели структурами с единственным полем 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
}
Исправление
stevejobs,
:
А может вообще считать указатели структурами с единственным полем 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
}
Исходная версия
stevejobs,
:
А может вообще считать указатели структурами с единственным полем value и делать разыменовывание как ptr->value
всячески за. должно снизить порог входа
Как следует выполнять взятие адреса?
как часто это предполагается делать? Может быть тоже сделать у каждого объекта поле «адрес»? опять же должно снизить порог входа
Циклы. Классический сишный набор for-do-while с сишным же синтаксисом?
лучше перевести фокус на стримы, а в первом релизе не делать циклов вообще
array.forEach (arg: int -> { ... })
Из-за этих операций возможны всякие странные вещи типа ++i + ++i. Так ли это плохо?
в новом языке нет легаси совместимости - можно просто задать порядок для таких операций, чтобы не было UB
reintepret_cast<тип>(значение)
для русского человека название неблагозвучно
я за автоматические методы типа x.toInt
можно префикс .to в названии метода сделать «специальным», и при наличии в классе метода с названием типа stringToInt подхватывать его для конвертации
или проще, сделать у всех метод .to, у которого первый аргумент - название типа. x.to(Int), а метод-конвертер ищется аналогично