sent to the C++ SG14 working group
I actually came across an interesting idea that I would love to see in the language while working on a shader reflection library (participants here in the game engine community already have likely worked with these systems ad nauseum).
One feature graphics engineers use liberally and to good effect in shader code is "component swizzling." Suppose we have a vec4 which is a packed struct of four single-precision floats. We can perform operations such as the following
vec4 color = ... // Some color value with components rgba
color.rr; // This is a vec2 initialized with values {color.r, color.r}
color.zyz; // Equivalent to a vec3 initialized with {color.z, color.y, color.z}
and so on.
A powerful overload C++ could provide to support this is as follows:
T operator.(constexpr char*, constexpr size_t)
Note that this overload only works provided that the (overdue) P1045 is accepted which allows us to leverage constexpr in the body of the implementation. An alternative would be to provide the literal as an NTTP (as demonstrated in the compile-time regex library with the GCC extension) but given the momentum behind constexpr, keeping the interface constexpr instead of relying on templates seems prudent.
For mathematical entities, the value of this user-defined property is unquestionably convenient and expressive (I think the shader code I write would be borderline unreadable without this facility). Beyond that, I can envision broader usage as well. For example, consider a JSON parser which has parsed JSON into a C++ object. It could override the property accessor to more conveniently provide runtime property lookup (as opposed to requiring that the user pass string literals). Any structure that has dynamically created keys (YAML, XML, HTML, etc) would benefit from such an interface.
Taking this one step further, property setters could be specified with another overload type:
decltype(*this) operator.(constexpr char*, constexpr size_t, T input)
This allows us to set a user-defined property given some input.
There is some mild collision of this proposal with the existing operator. overloading paper from Bjarne but ADL easily distinguishes between the "naked" operator. overload and this property overload.
Last, this feature would enable get/set property access/modification in a manner that can be intercepted by the type provider. This idiom is relatively common in other languages and sometimes referred to as a "proxy" (although proxy implies even broader interception that properties).
All feedback/comments are welcome, Jeremy
For those unfamiliar with the shader syntax discussed as a motivating use case here, please refer to this section of the GLSL specification