Для меня LValue это каким-то языковым образом представленный адрес памяти, где находятся данные. Именно уже посчитанные - иначе в случае LValue и быть не может.
Если это LValue, то никто не обязывает меня туда именно писать, хотя и разрешает.
Читать тоже разрешает.
А RValue, это выражение, посчитанное или нет - бабка надвое сказала
Настолько "надвое", что, как мне кажется - Count не будет работать 100%-но

Или по другому (в стиле мат.логики): LValue - это достаточное условие (надежное абсолютно) для того, чтобы не делать буферизацию.
Возможно - избыточно надежное. Условия необходимости - нет. Оно было бы, если бы у нас были претензии и писать туда. А таких претензий у нас нет.


С какой это радости, интересно.
Какое такое правило он нарушил, и что он должен делать, чтобы в код попало именно то, что хочется.


Ну, во-первых, я имел в виду статические элементы.
В этом случае любой длины "обточивание" разрешимо в Design-Time.
Даже в Fasm, без применения дополнительных интеллектов - это элементарно (хотя исключать глупостей и самых продвинутых компиляторов - нельзя).
Для динамических, кстати, в CPP была бы другая запись 'SDK_0->SDK_15->'

И про спорность и говорю, между прочим - не должно у нас ее быть.
Просто (в перспективе) у нас должен быть какой-то дополнительный флаг у кода "не нуждается в буферизации".
А знания эти должны произойти от пользователя 1-го уровня, и ниоткуда больше.
Да просто неоткуда больше

Именно этот пользователь (1-го уровня) для случая 'Applet.width*3/2' должен каким-то образом сообщить CG "потенциально нуждается"
А для случая return(d && '.data1.RefCount') сообщить "не нуждается", или наоборот - именно исходя из знаний языка, и особенностей компилятора.
И никаких спорных моментов.
Пользователь (1-го уровня) сам с собой поспорил, почитал буквари, и принял решение.
И все споры закончились - так должно быть, мне кажется.

А наша задача - дать ему физическую возможность "принять это решение", а не принимать за него.
Собственно, частично уже дали: ведь именно Пользователь 1-го уровня написал шаблон буферизации в direct.inc.
И именно он (в том смысле, что уж точно - не CG) отвечает за то, что после применения этого шаблона - флаг категорически устанавливается в "не нуждается"
Чистый LValue, между прочим....

---

Мысль-то основная в том, что использование Count вместо такого св-ва - не шибко-то и надежно.
Или по-другому: есть сомнения в достаточности условия Count(_data)>1
Мне понятно, что было бы удачно, если бы у нас такое уже мимоходом было бы.
Но не совсем так это... Разные немного вещи это....

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