-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
REDUNDANT S.R.CS.Unsafe: Revise API to accomodate for ref readonly
/in
#24399
Comments
Minimal alternative (though less convenient) is a method shaving off readonlyness: private int value;
void Main()
{
ref int refValue = ref Unsafe.Add(ref value, 5);
ref readonly int roRefValue = ref Unsafe.Add(ref value, 5);
//CS1510 A ref or out value must be an assignable variable
ref int refValue2 = ref Unsafe.Add(ref roRefValue, 5);
ref int refValue3 = ref Unsafe.Add(ref ShaveInOff(roRefValue), 5);
}
public static ref T ShaveInOff<T>(in T source)
{
throw null;
} cc @VSadov |
I think `public static ref T AsRef<T>(in T source) { throw null; }` can do that.
As you say this could be enough, if we can live with losing readonly.
|
This was discussed in https://github.com/dotnet/corefx/issues/23916. |
My mistake. Did not see when looking. |
ref readonly
/in
ref readonly
/in
BTW the concerns about aliasing that might not be guaranteed as discussed in #23504 was alleviated by allowing ‘in’ at the call site. Since AsRef relies on direct reference to the arg, it would make sense to always call it with explicit ‘in’. - to make sure there are no conversions, temporary copies, etc... AsRef(in someReadonlyVariable) |
Already discussed, see https://github.com/dotnet/corefx/issues/23916 and use:
REDUNDANT!
With the introduction of
ref readonly
return values andin
(i.e.ref readonly
) parameters the existingUnsafe
API should be considered for revision with respect to how to support these naturally.Rationale and Usage
Naturally support
ref readonly
usage in theUnsafe
API, to allow using this on readonly data.Proposed API
A tentative proposal for discussion:
One could also add the new methods to a new class
ReadOnlyUnsafe
which would make methods less discoverable, but make naming easier.Open Questions
How do we in general support adding new methods identical to existing methods but with
ref readonly
/in
, do we simply suffix withReadOnly
if it is not possible to simply change the existing method?Updates
Existing API
cc: @jkotas @mellinoe
The text was updated successfully, but these errors were encountered: