Ну это вопрос комфортности языка. И на чистом С тоже можно писать ООП.


Усложняем задачу

class
public:
   property state read mState write setState   
private:
  setState(state) { mState = state }
  mState

Если нужен виртуал, меняем приват на протектед с соответствующим ключевым словом.

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

Я предлагаю уменьшить количество кода, а также его сложность, чтобы легче дебажить, когда я могу заменить одно другим.
Давайте смотреть правде в глаза. Вы прекрасно понимаете, что "появилась идея, быстрей кодить"  с опытом проходит. Нефиг садится за комп без плана действий. Также вы прекрасно понимаете, что проект (проект как документацию)  программы создать невозможно. К примеру проект дома можно, таких строились тысячи. ПО - никогда. Нет, его делают, но от первоначального вида рожки да ножки остаются. Поэтому мы ходим этими грёбаными кругами, проектируем, отвергаем, опять по новому кругу. Короче рефакторинг. И без него, без планового рефаторинга, будет абзац. (кроме программы калькулятор). Мы создаём структуры и все такое. Структура - это же наш класс дебажный, и мы себе говорим - закроем потом переменные. Мне бы это упростило жизнь, если бы были проперти.

Ой, нет, не надо навязывать всем свою идеологию как за истину в последней инстанции..

Вот я смотрю чужой код, в котором автор направо и налево использует проперти.

C++ (Qt)
object.value = 123;
 

То что value - это проперти сразу так совсем не очевидно.. Казалось бы безобидное присваивание, но последствия этого могут кардинально изменить состояние всего объекта..
И ищи потом свищи, что потом пошло не так, что оказывается такое присваивание дёргает закрытый метод, который что то там ещё и делает исподтишка..
Не очевидность того, что происходит здесь и сейчас в когде - это как то явно в разрез с тезисом "легче дебажить"..    

Что значит не реализуемое? Я же привёл код который в точности воспроизводит механизм проперти)

В boost'е, например, и здесь на этом форуме https://www.gitorious.org/lightssp
И что?
А вы понимаете разницу между тем: что является непосредственной частью языка и каких либо реализаций (те же умные указатели) с помощью его же (языка) средств?
Это разные вещи.
Вы же нам категорически пытаетесь навязать (на примере проперти), чтобы они стали частью языка.


    

Прочитайте начало топика. Первый пост.
Я, что, к вам пришёл домой и паяльником стал угражать, пишите все с проперти? Или здесь сидит Страуструп и читает мои сообщения и думает - а это ИДЕЯ! Я просто высказываю свои мысли на расслабоне, сегодня суббота, весна настала, птички поют, а вы про какое-то навязывание.

Ну и  в ответ на ваш пост - нет, вы не правы. умные указатели стали частью языка (не в прямом смысле), т.к. приняты всеми, принята всеми их идеология и ценности которые они несут. Есть ли менеджеры памяти другие, да наверное тысячи. Как и библиотека STD является частью языка (официально), хотя к с++ не имеет никакого отношения.

И про нереализуемое - вы слишком буквально воспринимаете слова.

Рассуждения зашли в тупик. Какая искусственная сущность? Вы употребляете слова - гетеры/сетеры. Вот это искуссвенно. Вы эмулируете уже проперти. Какие примеры? Это что, новое что-то? да в других языках есть, куда примеры то приводить.

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

При виде такой строчки: a.value=10; вы будете морально готовы к тому, что это может быть property.

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

Эм, о чем это я? +1 за property на уровне языка в плюсах. К примеру, в шарпе отличные property.