-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SYCL][DOC] Update marray specification #12786
base: sycl
Are you sure you want to change the base?
[SYCL][DOC] Update marray specification #12786
Conversation
…er the deleted operators to follow the C++ order
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally, I question the need to explicitly delete operators, considering they are not automatically generated nor inherited from the generic marray. I propose an approach to only include the necessary operators for implementation (See 2nd commit: 300a22e).
You are right, they are not required to be explicitly defined, but I would argue that the benefit of defining them is that we express explicit intent. That is, by specifying that these operators are deleted, the user can easily see that we intentionally disallow them and it tells us that whoever wrote the extension thought about the operators and concluded that they should not be there and should not be added in the future.
sycl/doc/extensions/experimental/sycl_ext_oneapi_complex.asciidoc
Outdated
Show resolved
Hide resolved
I'm not opposed to this PR, but I think the entire section "Marray Complex Class Specialization" is not really necessary. The I agree that we need some documentation about which operators are available. There is a proposal in the Khronos issue DB that the SYCL specification should have general wording saying that each |
I understand your comment @gmlueck but do you believe that we should first fix the specification for what it already is? This PR is not the one that introduces the We could right after, open another PR that continues the conversation you started? (also asking your opinion @steffenlarsen ) PS: With the possible removal of the |
This is a good question. It seems like the base definition of |
As you said, the base definition of The specialization when first introduced, was here to add free functions that mimics the complex class.
We already had a discussion on these free functions, and we came to the conclusion that this should not be added to the The specialization is now just here to delete the inapplicable operators not supported by complex but does not add any optimization in the specialization. With your latest comment and looking at it with fresh eyes, makes me question the relevance of the specialization. Any counter arguments on this @steffenlarsen ? PS: The operators needed to be hidden friends, but the base |
Description
In response to feedback from @steffenlarsen on the specification implementation (#8647), several adjustments were made:
Question
Additionally, I question the need to explicitly delete operators, considering they are not automatically generated nor inherited from the generic
marray
. I propose an approach to only include the necessary operators for implementation (See 2nd commit: 300a22e).If agreed, the part that stipulates to delete the operators and the deleted operators in the inline code would be removed. (Explaining why this PR is a Draft)
If not, this raises a question for future implementers: Is it necessary to explicitly delete all operators, or can the declarations be omitted?