-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Champion "IntPtr operators" #48
Comments
I would like to propose four more operators: implicit unsafe operator void*(IntPtr);
implicit unsafe operator void*(UIntPtr);
implicit unsafe operator IntPtr(void*);
implicit unsafe operator UIntPtr(void*); as I am often working with a mixture of P/Invoke-calls (which do not care whether I use |
For your consideration I have also done some work on implementing |
I would suggest adding the following implicit operator long(System.IntPtr)
implicit operator System.IntPtr(int) implicit operator ulong(System.UIntPtr)
implicit operator System.UIntPtr(uint) Not sure I understand the need for the two below. Why are these needed? To support explicit cast? explicit operator System.IntPtr(System.IntPtr)
explicit operator System.UIntPtr(System.UIntPtr) |
I would also add comparison support for |
@nietras Concerning your last comment: We will not need to implement comparison operators explicitly, if the implicit-cast-operator from/to |
@Unknown6656 yes, of course 👍 😄 |
@nietras, comparison of As such, comparison operators should not be provided and I would further think that implicit conversion should not be allowed. |
@tannergooding this table also says you can't compare long l = 1;
int i = 2;
bool b = l > i; As far as I'm concerned, and I'm no expert, the intent of this table is not to say that you can't compare a
as you can see in https://github.com/DotNetCross/NativeInts/blob/master/src/DotNetCross.NativeInts/NativeInts.il#L781 Whether or not we then wan't implicit or explicit conversions should be based on the same guideline as for I do, however, understand that |
I see this has been labelled as "7.2 Candidate" was hoping for 7.1, any way we/I can help speed this up? I see next step is prototype... |
Alternative design: #435 dotnet/corefxlab#1471 |
I think the support for some of the operators on |
I notice the proposal does not explicitly state that the proposed operators should be "predefined operators" specifically for the C# language. The operators themselves do not need to be defined in metadata. This could be inferred by readers familiar with C# and the underlying IL, but it would still help to clarify it in the proposal. The distinction is particularly important for the compile-time handling of Also, the proposal fails to detail the behavior of checked and unchecked arithmetic with respect to the new operators. |
Yes. The proposal could definitely be more explicit on those points. I intended these operators to be implemented entirely by the compiler (as is done for the other runtime primitives) and for checked/unchecked handling to be treated the same. All of this is supported and clearly defined by the CLI spec, its just that the original language design (for whatever reason) decided against including the support for this primitive type (and only this one). |
How would the compiler know whether the following is an error (due to overflow) or not? const IntPtr x = (IntPtr)int.MaxValue + (IntPtr)1; |
📝 @tannergooding If you are happy with my explanation of proposed overflow handling in #435 you could copy it here, and/or modify it as you find appropriate. |
@sharwell Please help me understand how your proposal handles this: const IntPtr a = unchecked((IntPtr)uint.MaxValue + (IntPtr)1);
const bool c = a == (IntPtr)0; The bool |
I posted the answer on the other thread as well. The CLI spec explicitly defines that |
@tannergooding That does not tell me if |
This is an either/or with native int types #435, which we'd rather do. If we drop those, this will be back in consideration. |
The text was updated successfully, but these errors were encountered: