Assign to new pointer operator

[dylanrafael05]

Yes, I know I just made a proposal earlier today, but I'm a very bored person and I think this one might be of more use
This, again, is just a suggestion from a novice programmer, feel free to disregard
Sorry in advance if this post annoys anyone, I will delete if it receives negative feedback or is found to be a duplicate/inferior version of another discussion

In C#, there is no way to concisely create a new pointer which references a new variable. In most cases, programmers create a variable and set it to the desired value, then use the & operator to point the desired pointer to the value. In the end, this new variable does not have any use, unless mutation of the pointed-to value is immediately required. When storing pointers as fields, or returning them from a function, this is rarely the case. As such, I feel that it would improve the programming experience when dealing with pointers to have a simple operator which does this for you.

Possible Implementation

• a new operator, for instance &: or $

int* ptrToZero = &:0;
// OR
int* ptrToZero = $0;

This operator would not be overloadable. Downsides to usage; Might cause confusion with existing operators or add too much to the complexity of c#.

• a new usage of the & operator, which works for literals, constants, and values

int* ptrToZero = &0;

This operator would not be overloadable. Downsides to usage; Might cause confusion since &0 could be confused with (int*)0. Most viable option

• using new* or var* as a unary operator

int* ptrToZero = new* 0;
// OR
int* ptrToZero = var* 0;

Downsides to usage; Hard to implement, since both new and var have very specific uses already, both of which are quite unique, and therefore adding a meaning to either of them would likely be difficult to account for during parsing. Most aesthetically pleasing option

Possible uses

For demonstration purposes, the new* syntax will be used in the following examples

• For user-defined types containing pointers

public unsafe class Example {
   public int* int1;
   public Example() {
      int1 = new* 0;
   }
}

• For creating new pointers in methods that return a pointer to a new value not passed by parameter

public int GetValue() => 10;
public unsafe int* GetThatPointer() {
   int* ptr = new* GetValue(); 
   // single line declaration, as opposed to clunky dummy var declaration
   // the call to GetValue may call a function outside the user's code, so defining GetValue() to
   // return a ref int or int* is not always a viable option.
   //... rest of implementation
   return ptr;
}

• As a replacement to other clunky methods such as

public static GetPointer<T>(T t = default) where T : unmanaged => &t;
GetPointer<int>(10); 
//Although concise, still requires the creation of the above method or usage of external namespaces,
//despite its function being extremely basic to the concept of pointers.

Reasoning

The ability to create a pointer to a new variable feels like something which should exist as a built-in part of C#. C++ has ways to do it concisely, and it is not particularly prone to bugs from what I can theorize, so C# should allow it as well, both for sake of user experience and for thoroughness.

Sorry again, flf++

[huoyaoyuan]

Pointers are discouraged and very uncommon in C#. There shouln't be any shorthand for it.

[dylanrafael05]

Although discouraged, they are practically required to implement various optimizations (Unity DOTS uses them extremely often)

[bernd5]

In recent days we work havily with pointers - but not with "raw pointers" - with "ref / in / out" aka "managed pointers".
The benefit is that you do not have to dereference those and that the compiler executes some checks to avoid common errors (like returning a reference / pointer to a local variable).
Most of the time the built-in language tools are sufficient for working with "managed-pointers" - but not always.
For those cases the framework / runtimes provides a utility class called "Unsafe".

One example is if you dislike the conditional ref operator. See this discussion:
#4547

As I understand your propsal you want to combine:

int i = 42;
int* iPtr = &i;

to

int* ptrToZero = &42;

But this looks really weird to me - and it would work only for pure r-values / literals. You should write:

int i = 42;
ref int iRef = ref i;

And you wrote:

this new variable does not have any use

In my eyes this is not true. The new variable determines the lifetime of the variable.

[dylanrafael05]

The issue with managed pointers is their lack of utility, since pointers allow the manipulation of data behind the scenes that highly optimized code requires. Although many cases allow for usage of "ref" variables, some techniques, most prominently the usage of Unity's "Burst compiler", forbid the usage of managed types. Support for unmanaged pointers should be fully fleshed out before managed pointers, and managed pointers should be able to do everything which unmanaged pointers can and more. In their current state, I find raw pointers to be much more useful and logical than managed pointers.

[bernd5]

Under the hood "ref variables" are just "raw pointers" - just with enhanced checks and simpler usage (no unsafe, no deref). There is no performance penality.
With "managed types" we often refer to GC-managed objects (which can be moved by the GC). A ref var is not such a managed type - it is just like IntPtr or int* or nint.
What do you miss for ref?

[Joe4evr]

A ref var is not such a managed type

Hmm.... I'm pretty sure it is. That's an advantage of ref versus raw pointers; if the GC moves something that you were holding a ref to, the ref itself is updated to remain valid.

[bernd5]

Yes, you can get a reference to a GC managed type - which is completely disallowed with raw-pointers. Not just because of GC / fixing issues. With managed types you can only get a pointer to an unmanaged-type field in a fixed environment (to prevent moving).

But if you look only at unmaged types aka structs or values types the generated assembly is exactly the same:
small sample

[Joe4evr]

Yes, but when your struct lives on the heap for example inside an array, you need to keep it fixed in place to prevent the GC from moving your pointee. refs on the other hand will work without fixing because they are GC-managed.

[HaloFour]

The following looks like you're trying to get a null pointer to me:

int* i = &0;

I get the desire for wanting some kind of shorthand here, especially if it's something you do somewhat often. However, given that the pointer needs to point to a memory location, and the lifetime of that memory location dictates the safe lifetime of that pointer, I think it's critical that the developer explicitly declare their intent.

[bernd5]

In my eyes it is nothing. 0 is a literal / rvalue which has no address.
Nullpointer would be: int* i = null;