First draft of a KHR for properties

[gmlueck]

This is a WIP draft KHR for compile-time properties. The text of the KHR is not complete yet, and there are still some open issues, but I think it's far enough along to start getting feedback.

The open issues at the bottom refer to "the POC". This is a POC implementation of this KHR which I wrote only to flesh out ideas. For those who are interested, the POC is available at intel/llvm#21368.

[keryell]

I have made an implementation of this with 5 variations with the help of Claude Code CLI Opus 4.6 1M tokens: https://github.com/SYCL/properties

So it looks like using prop2<> as a key works for constexpr properties. @illuhad

[keryell]

Some other ideas on clean interface https://github.com/qlibs/mp

[VerenaBeckham]

I love the idea of compile-time properties, but does Intel have a killer use-case for them right now? As I understand it, all the existing SYCL properties would remain "runtime properties" as described by this KHR. Also, in the "free function commands KHR", which now depends on this KHR, I can't immediately see a property that would be implemented as a compile-time property, unless I missed it?
Is there a compile-time property that you are intending to introduce once this KHR is merged?

[gmlueck]

Is there a compile-time property that you are intending to introduce once this KHR is merged?

The reason we proposed this KHR now is because we want to use it in #922. We'd like to replace the khr::requirements class template with the new khr::properties. The khr::requirements is very similar to khr::properties, but it's not as general. If we can settle on the compile-time properties KHR, then we can avoid defining khr::requirements at all, which will simplify the overall API surface. It will also improve #922 because we can use the new khr::properties in the future to pass kernel launch properties to those APIs. Intel has a number of kernel launch properties in our extensions already, and I expect we will want a standard way for vendors to pass properties when launching a kernel.

[TApplencourt]

> The properties defined and illustrated in this extension are all in the sycl::khr namespace rather than some nested namespace like sycl::khr::properties. If this KHR is adopted into the core spec, properties will be defined directly in sycl. This was intentional in order to reduce verbosity in applications that use the extensions. Is this a good idea, or will we end up polluting the top-level SYCL namespace with lots of properties?

Done

> The properties constructor has a Mandates that no two properties in the list have the same key. Does it make sense for this to be a Mandates instead of a Constraint? I think the error message will be better with a Mandates, but you could make that same argument for other cases where we decided to use Constraints anyways.

Not allowed: 
- plist.has_property_list<prop_1<false>, prop_1<true>>;

- C++: Mandates versus Constraint
	- Mandates: Compile Time
	- Constraint: "no overload matching"
		Allow: - if require 
					 - else 
	- Nevin Todo: When does the C++ choise to use Mandates or Constraint.

- No exception for plist.has_property_list<prop_1{true}, prop_1{true}>;
	- To much compile time overhead.
	- Imposible to do for runtime value

> Should we define operator== and operator!= for every property? The DPC++ extension has this, but I left it out of this KHR because they didn’t seem very useful to me.

- Can use `decltype` for get/has in CTS.
- WG vote to go without `==` and `!=`

> Should we define operator== and operator!= for the properties list? This would require metaprogramming to deduce EncodedProperties as the sorted list of Properties, otherwise two properties lists constructed from the same set of properties would have different types if the properties were specified in a different order. The DPC++ extension has this, but I left it out of this KHR because the comparison operators didn’t seem that useful, and I didn’t think it was worth the extra complexity required to sort the properties. Sorting the properties (via metaprogramming) would also slow down compilation (because the properties would be sorted at compilation time), and I didn’t want to impact compilation time by adding this sorting requirement. However, I defined the properties constructor in such a way that we could add this sorting as a later revision of this KHR.

auto p1 = sycl::property_list{ p1, p2 };
auto p2 = sycl::property_list{ p2, p1 };

static_assert { p1 == p2 };

- N^2 algorithm
- Property and property list will not follow SYCL "Common reference semantics", neither "Common  by-value semantics"
- Not possible to be implemented in user-space.
- WG vote to go without `==` and `!=`
- Potential to Add KHR section "Limitation"

> Can we guarantee that properties is trivially copyable unless it contains a runtime property that is not trivially copyable? The POC uses std::tuple to implement properties, and std::tuple is not trivially copyable. As a result the POC version of properties is not trivially copyable. This seems like it should be fixable, though, because the DPC++ version is trivially copyable.

- If `property_list` trivialy copyable, can be passed as Kernel Argument?
	- tuple is currently potentially `Device copyable`.
	- When all compile time, don't need a tuple, so trivial to make it "trivial copyable"

- For the same argument of simplification, we don't say anything.  WG vote to go without the `trivially copyable` requirement

> This KHR already defines the trait is_property_list_for, but should it also define the trait is_property_list? It turns out that none of the APIs in this KHR need is_property_list to implement any of their constraints, but maybe this trait would be useful to users who want to create a utility function that takes a generic properties list?

`is_property_for_v<in_order, queue> == true`
`is_property_for_v<sub_group_size, queue> == false`
`is_property_list_for_v<plist, queue>` == plist.all?

- WG vote for don't add it `is_property_list`. Also maybe easier in C++26 introspection