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

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

бугага

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

тут придется с каждым Character таскать еще и vtbl

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

если же ты считаешь, что язык «выше» конкретного класса Character, то все равно тормозность — это свойство языка; например, отсутствие или наличие *гарантии* оптимизации, для примера — http://en.wikipedia.org/wiki/Return_value_optimization

з.ы. наверно я продолжу дискуссию про неявный return

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

бугага

рассмотрим язык, где *все* класс, в том числе и Character (символ юникода) является классом, т.е. от него можно наследовать, добавляя виртуальные функции, причем прямо в рантайме — тормоза и расход памяти неизбежны, т.к. в 3 байта такой Character не поместится (а еще лучше, когда язык не ооп, а prototype-based, и юзеры могут это юзать в рантайме)

тут придется с каждым Character таскать еще и vtbl

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

если же ты считаешь, что язык «выше» конкретного класса Character, то все равно тормозность — это свойство языка; например, отсутствие или наличие *гарантии* оптимизации, для примера — http://en.wikipedia.org/wiki/Return_value_optimization

з.ы. наверно я продолжну дискуссию про неявный return