@Mark Hoemmen Thanks for referring me to the mdspan proposal. Allowing specification of custom layouts is definitely a good idea. If not just to support column major layouts (as opposed to row-major) for SIMD efficiency for example (or interoperability with shader data layouts which tend to be column-major). I'll look into it further to see how much sense a tiled layout would be as a possible initial set of "provided" layouts.

To the rest of the list, 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:

    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

On Mon, Dec 16, 2019 at 2:43 PM Andrew Lumsdaine via SG14 <sg14@lists.isocpp.org> wrote:
We should loop Peter Gottschling into this discussion as he implemented this for MTL4.

Best Regards,
Andrew Lumsdaine
(Sent from portable device, please excuse brevity and typos.)


On Dec 16, 2019, at 1:18 PM, Hoemmen, Mark via SG14 <sg14@lists.isocpp.org> wrote:



On 12/11/19, 2:24 PM, "SG14 on behalf of Jeremy Ong via SG14" <sg14-bounces@lists.isocpp.org on behalf of sg14@lists.isocpp.org> wrote:

> This is a bit out of left field, but I'd be interested in a data structure adapter which packs its elements based on Morton codes (or some other space-filling Hilbert curve, see https://en.wikipedia.org/wiki/Z-order_curve).

 

Greetings!  It should be possible to write an mdspan (P0009) Layout that uses a space-filling curve to order its elements.  I’ll be happy to talk with you more if you’re interested.  The main purpose of mdspan’s Layout customization point is to optimize array layout for the computer architecture and parallelization scheme – e.g., to ensure coalesced access on GPUs and improve spatial locality on CPUs.  Users can write custom Layouts, but if you think a space-filling curve Layout should be part of the standard, please let me know and I’ll bring it up with the other P0009 authors.  That would likely be offered as a follow-on paper.

 

Thanks!

Mark Hoemmen

_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14