You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The generated bindings for vkCmdUpdateBuffer have the pData parameter marked as ref (or Span<T> for the Span overloads), rather than in or ReadOnlySpan<T>. The official documentation for vkCmdUpdateBuffer has the pData parameter marked const.
These parameters should be treated like other const parameters, and take an in or ReadOnlySpan<T> argument.
Steps to reproduce
N/A
The text was updated successfully, but these errors were encountered:
While you're right from a C++ view, we currently generate C# bindings from the vk.xml file provided by khronos.
In addition using in has the drawback of allowing implicit usage, which has often shown to be a drawback, and we prefer ref wherever possible.
Using ROSpan would be preferable though, I doubt this will change in 2.x though, but 3.0 should be able to do this.
Just going through the 3.0 issue backlog. We have decided in the most recent working group meeting that following const correctness with the 3.0 style of overloading resulted in a significantly worse-off user experience and we are instead moving to an analyser-based const correctness approach.
So to address the actual issue here: SilkTouch 3.0 is already capable of recognising const correctness, and will annotate the function here. It will also likely be the case that you can pass a ReadOnlySpan into these functions, and the analyser warn if this is invalid to do.
To this end, I believe this issue is already as complete as it will be for 3.0, but I will leave it open until we've validated that we can indeed pass a ReadOnlySpan into these functions.
For more information, we encourage readers read the 3.0 proposals in #1727 (basically final, just need some minor edits) and/or watch the 3 hour livestream on the .NET Foundation YouTube channel in which we discussed our decisions in great detail.
Thoughts on the ReadOnlySpan castability @curin? I forget where we got on the SilkX effort here, but given the WG is already on board with the analyser based approach here, it wouldn't be an addition that goes against WG-approved precedents.
We didn't add the analysers yet and ReadOnlySpan cast wasn't added in the submitted version, only Span, but I think analysers will be important for cases like this, and adding a ReadOnlySpan override shouldn't be difficult for either Ref or Ptr types.
Summary
The generated bindings for
vkCmdUpdateBuffer
have thepData
parameter marked asref
(orSpan<T>
for the Span overloads), rather thanin
orReadOnlySpan<T>
. The official documentation forvkCmdUpdateBuffer
has thepData
parameter marked const.These parameters should be treated like other
const
parameters, and take anin
orReadOnlySpan<T>
argument.Steps to reproduce
N/A
The text was updated successfully, but these errors were encountered: