[Proposal] Allow set operator when calling a method => ".="

[AdrienTorris]

Sometimes, when I update the value of a variable using a method, I forget to set the equal, and it can be a bug hard to find because the code looks good.

The idea here is to allow to update the value of a variable using a methods with a syntax near than this one :

int i = 0;
i += 1;

And could result code blocks like :

DateTime dt = DateTime.Now;
dt.=AddDays(1); // the value of _dt_ is updated

Or :

List<SomeClass> list = // get data
list.=OrderBy(x => x.Position); // _list_ is now sorted by position

[DavidArno]

var now = DateTime.Now;
var thisTimeTomorrow = now.AddDays(1);

var list = ...;
var listSortedByPosition = list.OrderBy(x => x.Position);

Why overload a single variable with multiple meanings? If you create a now value, it has a new meaning, so give it a new name.

I am opposed to suggestions like .= as they encourage what I view as being bad coding practice.

[AdrienTorris]

1: I didn't call my variable now
2: The DateTime.Now value was just an example
3: Sometimes in programs, the values of variables can change, this things happens ...

[AdrienTorris]

A problem can occurred if the output format of the method is different than the format of the variable, like this case :

string s = "this is a string";
s.ToArray();

In this case, s.=ToArray(); will throw a CS0029 compilation error.

But you can do the same error today :

string s = "this is a string";
s = s.ToArray();

And the same result, a CS0029 compilation error, is a good behavior in both cases.

[GeirGrusom]

var match = Regex.Match(input, pattern);

while(match.Success)
{
  Foobar(match);
  match .= NextMatch();
}

[DavidArno]

foreach (var match in new Regex(pattern).Matches(input))
{
    Foobar(match);
}

Which more than adequately illustrates my point. @GeirGrusom's Regex.Match example results in a mutating variable and complex code, that is hard to read and prone to bugs. A .= shortcut would then just encourage continuing going down that rabbit hole by making it easier to write such bad code.

Instead, if one stops and thinks "can I avoid mutating match; is there a better way?", then one is more likely to end up with the simpler, more robust solution that I've used.

[lachbaer]

The DateTime.Now value was just an example

Yes, I think that in many discussions here the participants fixate too much on the concrete samples given insead of seeing them only as one potential case study. There needn't always be a very concrete RL scenario by the time the discussion/proposal is made. Many times the usefulness comes with the feature when you start using it and say "hey, didn't know that I was looking for it but it feels good" 😃 For issues named "Feature Request", as being stated as a concrete 'request', I would expect a real world practical use case scenario where the practical benefit for the specific situation is described.

About the proposal

I consider it inexperience to run into those kinds of mistakes, no offense! We all have our habitudes (human factors, bla bla bla... 😁 ) . But this time I have to concur with @DavidArno that I perceive it as a dangerous construct that really promotes mutability. Rather than treating the symptom, in this case the cause should be resolved.

[lachbaer]

@AdrienTorris Don't give up on it too quickly 😃 You only had 3 reactions out of 100s. Maybe the other 97 vote in favor of this? You never know.

It would be nice to have a final comment from you, why you revoked this proposal and closed it.

One argument against the chosen operator syntax. .= is used in PHP to append another string to an existing string variable. This operator could confuse new C# programmers with a PHP background, because their syntax has many similarities.

[AdrienTorris]

@lachbaer I closed this issue because you guys seems unanimous about the low interest of this issue, but I just want to be constructive. If 100s people take the time to read this issue and loose their time, it's couter productive.

I never used PHP so I didn't know that this operator already exists in this language. I chose this syntax because I found it readable and instinctive. The equal in second position already exists in C# (+= for example), and the dot in the first position was to not have a breaking change in the way to call a method, so the .= looked like as a good candidate to me.

About the mutability issue you speak about, I find this point very interesting but I don't really see the problem here. The mutability of an object is managed by the Framework so I don't see the bad thing about promoting mutability. When you use the += operator on a string, you are using mutability (I know it's not the case, that all the strings are immutables in .NET and that the framework creates a new string but this background process is hidden to the developer, so it's looks like mutability), and I don't see the bad practice of using it (except performance issues). But maybe it's a lack of knowledge for my part, I feel that I have to dig a little more the .NET framework.

I tried to find a really good real-world example to illustrate this issue and show how this operator could be usefull and more than a little syntaxic-sugar item, and I didn't find one.
If I find a real good example, I'll reopen this issue but meanwhile, I prefer to close it and not loose the time to more people.

[jnm2]

When you use the += operator on a string, you are using mutability (I know it's not the case, that all the strings are immutables in .NET and that the framework creates a new string but this background process is hidden to the developer, so it's looks like mutability)

Fyi you're mutating the variable from pointing to one immutable string to pointing to a new immutable string.

The mutability of an object is managed by the Framework so I don't see the bad thing about promoting mutability.

I agree with you. C# is multi-paradigm and the mutable and procedural paradigms are on equal footing with the immutable and functional paradigms. I have this crazy idea that C# should continue to be really good at both. ;-)

[GeirGrusom]

@DavidArno what surprised me is that Matches() is not the same as writing NextMatch() so there could absolutely be a bug in my example if the match was zero length but successful. Although a zero-length match is probably a bug to begin with, my code would cause an infinite loop whereas your code would at least terminate.

[jnm2]

@GeirGrusom

Although a zero-length match is probably a bug to begin with, my code would cause an infinite loop whereas your code would at least terminate.

I use zero-length matches all the time. I didn't think this was how the Regex engine worked, so I tried to create an infinite loop with your code and cannot. Can you?

[jnm2]

@GeirGrusom

I don't see any difference between the call the MatchCollection enumerator makes (via) and the call that Match.NextMatch makes.

[GeirGrusom]

Hmmm I could swear that I got an inifinite loop the other day, but perhaps I just didn't assign NextMatch() properly.

[Tvde1]

The irony!

[aluanhaddad]

@AdrienTorris I really want to second @lachbaer and urge you to reopen this proposal.

In addition, I want to add that

1. I think this idea is terrible.
2. While I cannot speak for anyone else, I have no authority over the adoption of features.
3. Adoption of features is not decided by the upvotes, downvotes, or comments of the C# GitHub community.
4. These discussions are great, thank you for taking part in them.

[AdrienTorris]

@aluanhaddad I don't really see the point to see a discussion about a proposal which everybody find bad keeps going on but if it's the whish of the community, I accept, let's reopen this.
I'll let Microsoft the decision to close it now.

[lachbaer]

@AdrienTorris The essential of this idea, namely reducing the repeating occurances of object names, pops up quite often. The need for this across other languages as well lead to the introduction of VB's With and chaining patterns, like the ones IEnumerable<T> has for LINQ expressions, or the one builder patterns use.

So, this discussion is absolutely valid and vivid. Maybe some reader comes up one day with the solution to this for C#, maybe even a C# team member? :-)

[ghost]

@AdrienTorris: I think it'd be better if we take something like "With" (Please refer to VB.NET: https://docs.microsoft.com/en-us/dotnet/articles/visual-basic/language-reference/statements/with-end-with-statement). We should focus on HOW TO WRITE SIMPLE WHEN MEETING WITH MULTIPLE PROPERTIES FOR A CERTAIN OBJECT.

We can import "with" (The first letter is a lower character) in C# (or create another new keyword such as "within"……ect) and we can say:

Rectangle r = new Rectangle();
r.Width = 3;
r.Height = 5;
r.Color = Color.Red;

to

Rectangle r = new Rectangle();
within r
{
    .Width = 3;
    .Height = 5;
    .Color = Color.Red;
}

And sometimes, we should bind multiple events to the same function with the same delegate (in VB.NET we have "WithEvents"). C# should also have such a keyword to simplify our coding.

[lachbaer]

@MaleDong the with keyword is already bound to Record Types. Using it for a similar, but different construct is confusing.

Nevertheless, I had the exactly same idea, but haven't come up with an idea for a nice syntax yet

1. the . should be ommited, like for object initializers
2. the 'with' block should only consist of member assignments or direct method calls, without chaining
3. statements are not allowed.
4. the member calls shall be seperated by , instead of ;, like for object initializers

Maybe a combination like using with aims the goal?

using with (Rectange r = new Rectange())
{
    Width = 3,
    Height = 5,
    PrintTo(Console.Out)
}

Question: shall using call Dispose when available in this case? Other idea obj...{}:

Rectange r = new Rectange();
r...
{ Width = 3, [...] }

(but that looks odd to me).

[DavidArno]

Why would I want to type:

Rectangle r = new Rectangle();
within r
{
    .Width = 3;
    .Height = 5;
    .Color = Color.Red;
}

When a shorter form already exists?

var r = new Rectangle
{
    Width = 3,
    Height = 5,
    Color = Color.Red
};

[AdrienTorris]

I agree with @DavidArno. Furthermore, the purpose of this issue is more about the update of an object than his instanciation.

[lachbaer]

@DavidArno @AdrienTorris

Why would I want to type

Because you could not only initialize properties directly after the creation of the object, but also call methods on it. And you can do that later on mutable objects as well ( @DavidArno I know you loathe them ;-) And you mustn't take the examples too literally, they just want to clarify how the construct should be used. But to whom am I telling this... 😄

(PS: with in (r) is good, because it doesn't introduce a new keyword.

[ghost]

@lachbaer：
Besides your worry about whether "using" will call "IDisposible" or not, there's another confusion. Let's take a close look at your sample given below:

using with (Rectange r = new Rectange())
{
    Width = 3,
    Height = 5,
    PrintTo(Console.Out)
}

What should I do if I wanna use "r" out of the "using with" block？ The lifeline of "r" is only in the block of "using with"？ This will make others puzzled.

Based on the two reasons, I have to say that I don't think using with……a good idea, though it looks nicer:(

An easy declaration of a veraible by multiple assignments is just to mock what we do in VB.NET. That's enough, clear and simple.

If you don't wanna import "with" into C#. Another idea is just using something like this:

Rectangle r = new Rectangle();
r.= {Width = xxx, Height = yyy,……Property = Value};

//Here you can also use it with "using":
using(r.= {Width = xxx, Height = yyy,……Property = Value})
{
    r.XXX=……;  //This could be also OK
}

//The above snippet of codes will be analysed like this:

using (r)
{
     r.Width = xxx;
     r.Height = yyy;
     r.Property = Value;
    ……
    //Do what you wanna here
}

The syntax for multi-assignments is:

declaration of a variable (e.g: a);
a .= {Property1=Value1, Property2=Value2,…PropertyN=ValueN};

The new operator ".=" just means "multi-prop assignments". After it we must use a block by “{}”, with properties there, seperated by a comma.

What's more——I don't suggest "Function-calling" in the new syntax created by me. Because this is PURELY for prop-assignments.

What do you think of this?

[AdrienTorris]

Similar discussion : #1887

[jeme]

@DavidArno Actually, I have come to hate object initializers over time due to the fact that when one piece fails, it's hard to know which one.

I would say that this is due to a miss-use of the feature but, but I have seen such problems enough times by now for me to avoid it all together...

Note though, I would certainly not say that it's an argument for the suggestion in this issue or for any of the with/within constructs... Just wanted to throw a negative view in on the supposed object initializer "better syntax" you outlined.

[jnm2]

@jeme The debugger team could enable substatement-level stepping, and that would enable the syntax to be used on its own merits rather than with a tooling side effect.

[jeme]

First of, appolygy for a reply on an acient issue, it popped up in my inbox today for some reason.

I might have missunderstood your initial thought here, your input is focused purely on stepping during a debug session in e.g. Visual Studio? - That is actually less of a problem.

I will largely stay away from Object initializers untill the following is true:

 1: public class Program
 2: {
 3:     public static void Main()
 4:     {
 5:         string str = null;
 6:         Foo foo = new()
 7:         {
 8:             A = "",
 9:             B = "",
10:             C = "",
11:             D = str.Substring(1),
12:             E = ""
13:         };
14:     }
15: }
16:
17: public class Foo
18: {
19:     public string A { get; set; }
20:     public string B { get; set; }
21:     public string C { get; set; }
22:     public string D { get; set; }
23:     public string E { get; set; }
24: }

ERROR:
Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
   at Program.Main() in E:\Workspace\EXPERIMENTS\Experiments\ConsoleBla\Program.cs:line 11

However it currently gives:

Unhandled exception. System.NullReferenceException: Object reference not set to an instance of an object.
   at Program.Main() in E:\Workspace\EXPERIMENTS\Experiments\ConsoleBla\Program.cs:line 6

That small difference that it reports the line of where the initializer start (Line 6) rather than the line where the actual error occures (Line 11) has been a huge annoyance for me.

---

Note: The same issue occurs for method chaining (e.g. fluent interfaces), and should in theory be equally annoying. I have however not been hit quite as hard and often by those.