[Proposal]: Introduction of the =. Operator for In-Place Method Calls with Assignment

[BN-KS]

Rationale:
The primary rationale for introducing the =. operator is to reduce errors, code size, and typing effort when performing in-place operations on variables. This operator aims to provide a streamlined and intuitive syntax for invoking methods that modify the variable directly, enhancing code readability and maintainability.

Proposal:

New Syntax: myvar=.someMethod(parameters); //assigns myVar to the return of someMethod

This syntax reduces the need for repeated references to the variable, minimizing the potential for errors and making the code more concise.

Syntax Definition and Example:

Syntax Definition:

myvar=.methodName(parameters);

Example:

string myDescriptiveVaribaleName = "Hello this world";
...
myDescriptiveVaribaleName=.Replace("this", "that");
Console.WriteLine(myDescriptiveVaribaleName); // Output: Hello that world

Simplete and cleaner than alternative: myDescriptiveVaribaleName = myDescriptiveVaribaleName.Replace("this", "that");

Compatibility and Conflicts:

The proposed .= operator should not conflict with existing C# syntax. Here are the key points regarding compatibility:

1. Backward Compatibility: The introduction of the =. operator does not interfere with existing operators or syntax. It introduces a new operation distinct from current member access and method calls.
2. Parser Considerations: Updates to the C# parser (Roslyn) would be required to recognize and correctly parse the =. syntax. This change involves ensuring the parser can distinguish between =. and other dot-based syntax elements.
3. Runtime Behavior: The runtime behavior must ensure that the method call on the right-hand side of =. modifies the left-hand variable directly, similar to how += and -= modify the left-hand variable by applying an operation.

Implementation Details:

• Compiler Changes: Updates to the Roslyn compiler to support parsing and emitting the =. operator.
• Type Checking: Ensure the return type of the method call is compatible with the type of the left-hand variable.
• Error Handling: Proper handling of null references, invalid method calls, and type mismatches, with appropriate error messages.

Similarity to += and -= Operators:

The += and -= operators in C# are compound assignment operators that perform an operation and assignment in one step. They work by:

1. Evaluating the right-hand expression.
2. Applying the operation to the left-hand variable.
3. Assigning the result back to the left-hand variable.

The =. operator can follow a similar model:

1. Evaluate the method call on the right-hand side.
2. Apply the method's result to the left-hand variable.
3. Assign the modified value back to the left-hand variable.

Date: 2024-07-19

[KennethHoff]

I don't understand what it does. Is it a shorthand for this?

// Current
string a = "hey";
a = a.Split(...);

// Proposed
string a = "hey";
a .=. Split(...);

That seems like a lot of effort for incredibly little gain.

[BN-KS]

Good variable naming conventions are to make it as descriptive and accurate as possible, so think of this:

//Any of these three look better:
myLongDescriptiveNameForSomethingSpecific =.Replace("example","test");
myLongDescriptiveNameForSomethingSpecific.= Replace("example","test");
myLongDescriptiveNameForSomethingSpecific.=.Replace("example","test");

//When compared to the current:
myLongDescriptiveNameForSomethingSpecific = myLongDescriptiveNameForSomethingSpecific.Replace("example","test");

Another option would be to let you start a statement with the = sign and then take the first variable as the argument:

=.myString.Replace("this","that");

Another challenge is that C# will keep the full variable names because of reflection/introspection so it really does impact the size of all the files whereas this one compiler improvement has exponential gains for everyone!

[TahirAhmadov]

I don't like this because:

1. When you have an immutable value (like a string) A, and you apply a change to it using a value-returning method (like Substring, etc.) which returns value B, that value B should be assigned to a new variable, and not used to overwrite the original variable. It helps with debugging, and is more consistent with functional style of programming.
2. Particularly with strings, every method call creates a new string instance, while this isn't a huge issue in many scenarios, it can become an issue inside loops and other hot executions paths.

I'm not saying you should stop using these methods full stop, but given these concerns, I'm not sure it's a good idea to make a language feature which simplifies this pattern any further.

[TahirAhmadov]

Regarding your point:

C# will keep the full variable names because of reflection/introspection

Can you elaborate? Do you mean decompilation?

[BN-KS]

Regarding your point:

C# will keep the full variable names because of reflection/introspection

Can you elaborate? Do you mean decompilation?

Apologies, 'variable' was to encompass 'in-line variable name, variable property names, variable field names, etc...' any conditionally named thing by the user, many of which are needed by things like reflection. Essentially if it is assignable this is a simplification to not having to write it twice

[BN-KS]

As an alternative we could allow "ref" and "this" to be used as the first parameter on an extension method by the compiler (like VB) so that at least we have a cleaner workaround for this.

https://stackoverflow.com/questions/2618597/impossible-to-use-ref-and-out-for-first-this-parameter-in-extension-methods