Clarify behavior when wrong property is passed

[gmlueck]

This question came from our development team.

The specification does not say what should happen if an incompatible property is passed to an API that takes a property_list. Here is a list of the APIs that take a property_list. I don't think any of them currently specify the behavior when an incompatible property is passed.

• context constructors
• queue constructors
• buffer constructors
• unsampled_image constructors
• sampled_image constructors
• accessor constructors
• host_accessor constructors
• local_accessor constructors
• unsampled_image_accessor constructors
• host_unsampled_image_accessor constructors
• sampled_image_accessor constructors
• host_sampled_image_accessor constructors
• usm_allocator constructors
• malloc_device, aligned_alloc_device
• malloc_host, aligned_alloc_host
• malloc_shared, aligned_alloc_shared
• sycl::malloc, aligned_alloc
• reduction functions
• compile, link, build (kernel bundle)
• stream constructors

I think there are two reasonable options:

1. Mandate that these APIs throw errc::invalid in this case.
2. Add a precondition that the properties are compatible with the given API, which means that the behavior is undefined if they are not.

[KseniyaTikhomirova]

I want to add one more thing to consider against option #2. What to return when someone sends incorrect runtime property and we ignore it stating that it is UB but then call get/has_property with it? Then it seems to be declared as UB also but in reality it will work and user will never know that the scenario is incorrect.