@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_at_[hidden]> 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_at_[hidden]>
> wrote:
>
> 
>
> On 12/11/19, 2:24 PM, "SG14 on behalf of Jeremy Ong via SG14" <
> sg14-bounces_at_[hidden] on behalf of sg14_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>