Suggest adding "with" statement to C#

[rushfrisby]

This would work similar to the VB With statement

The syntax in C# could look something like:

with(person)
{
    .FirstName = "Rush";
    .LastName = "Frisby";
}

alternatively it could look like:

person.
{
    FirstName = "Rush",
    LastName = "Frisby"
};

or both ways!

This seems reasonable seeing as how there is already some behavior like this for object initialization.

[ufcpp]

https://blogs.msdn.microsoft.com/csharpfaq/2004/03/11/why-doesnt-c-have-vb-nets-with-operator/
https://github.com/dotnet/csharplang/blob/0709623617764880198f972d66845e88a89fe149/meetings/2015/LDM-2015-03-25-Notes.md

[yaakov-h]

Related: #133.

[bondsbw]

@ufcpp I may have to *gasp* disagree with Jon Skeet on that.

A with operator (combined with braces) encourages grouping interactions with the object. That is clearer than the alternative, and I feel it is one motivation behind today's initializer syntax.

That said, I like its current proposed form as an easier way to work with immutable objects.

[bondsbw]

@yaakov-h I don't think #133 is related.

[HaloFour]

@bondsbw

It wasn't Jon Skeet's opinion, he was just reblogging this post from Scott Wiltamuth.

With var and simple named variables I don't find with particularly compelling, even if you avoid the massive design cluster-fudge that ended up in EcmaScript. I even recall proposals in VB.NET to modify With to have the ability to "name" the target expression, which is basically the same thing.

[bondsbw]

Fair enough, and this proposal (and that link) addresses a with statement. I was also considering a with expression which can be more useful in expression-bodied contexts.

[rushfrisby]

Scott Wiltamuth's arguments against with were valid-ish back in 2004 since the language was new but not so much any more. With the expectation that variable names should be well-named to minimize comments fragmenting readability this makes even more sense, as well-name variables are usually longer. This is the scenario which led me to creating this issue. Take the following for example:

var updatedCustomAction = MappingHelper.Map<DbCustomAction>(customAction);
updatedCustomAction.CreatedBy = existingCustomAction.CreatedBy;
updatedCustomAction.CreatedOn = existingCustomAction.CreatedOn;
updatedCustomAction.UpdatedOn = DateTimeOffset.UtcNow;
updatedCustomAction.UpdatedBy = currentUserId;
updatedCustomAction.DeletedBy = null;
updatedCustomAction.DeletedOn = null;

versus

var updatedCustomAction = MappingHelper.Map<DbCustomAction>(customAction);
with(updatedCustomAction)
{
	.CreatedBy = existingCustomAction.CreatedBy;
	.CreatedOn = existingCustomAction.CreatedOn;
	.UpdatedOn = DateTimeOffset.UtcNow;
	.UpdatedBy = currentUserId;
	.DeletedBy = null;
	.DeletedOn = null;
}

which is a lot easier to read in my opinion.

[yaakov-h]

@bondsbw you're right, I somehow got the wrong issue number.

I meant #803, though #77 and #162 are more closely related to your specific examples, I think.

[srburton]

@rushfrisby

Sugestion

var updatedCustomAction = MappingHelper.Map<DbCustomAction>(customAction);
with updatedCustomAction
{
	CreatedBy = existingCustomAction.CreatedBy,
	CreatedOn = existingCustomAction.CreatedOn,
	UpdatedOn = DateTimeOffset.UtcNow,
	UpdatedBy = currentUserId,
	DeletedBy = null,
	DeletedOn = null
}

[WrongBit]

Before I offered same 'with' operator and now also support rushfrisby's offer. It's so obvious simplification of code that it's surprise to me people didn't implement it yet, but discuss "how to make total mess, introducing 'class ABC (some variables)' rubbish". Above just "votes" C# team should use brains to filter really helpful features. When they made object initializers, THAT was "almost WITH operator", but half-baked due to narrow vision. Now we again and again ask for absolutely simplistic thing - introduce "with" statement which will clean-up boilerplate code.

[HaloFour]

@WrongBit

The C# team hasn't offered with because they haven't found it compelling enough to be worth championing through the language design process. That process is not driven by "votes", particularly not from here. The language curation process is lengthy with an exceptionally high bar due to the vast cost in implementation and support, the vast majority of proposed language features will fall way short of that threshold.

My opinion is that the with feature simply doesn't make the cut in terms of being useful enough to implement. It doesn't solve any problems nor does it appreciably reduce verbosity. Whether or not you like it you can easily achieve the same results by simply assigning an expression to a temporary variable with as terse of a name as you'd like. I think that any language feature would have to demonstrate that it offers more than trading a few characters in an identifier with a few characters in an indentation.

[HaloFour]

@WrongBit

Sorry, but today we cannot afford to waste time on boilerplate code!

But I insist - anything what reduces repetitive/boring typing should be implemented.

It's not a goal of C# to make the language as terse as possible. The difference in verbosity between a proposed with statement and assigning an expression to a single-character identifier is negligible at best.

Even if this proposal was less verbose by a noticeable degree, that's still not enough of a reason for it to be added to the language. It has to fit in to the design goals of the language design team and be deemed worth the massive amount of time and effort to implement and support for perpetuity.

Esp. when it's not "unknown, doubtful feature", but operator from existing language with predictable logic and usefulness.

You're free to use those languages. MS even ships one..

[YairHalberstadt]

@WrongBit

First you state:

Above just "votes" C# team should use brains to filter really helpful features.

The you state

That's why request of real developers on C# have nothing common with features C# team implements.

These statements seem to be in contradiction to each other. First you suggest the C# designers should not listen to what developers ask for and should make their own decision, then you suggest that they should not make their own decisions but should do what people ask them. Which is it?

Regardless this request has neither votes, nor backing by the LDM, so either way is unlikely to happen.

[franchyd]

This is just rehashing this conversation: dotnet/roslyn#6553

[mburbea]

@WrongBit, I don't see why this can't be solved with some previously suggested library method to let you give it a nice scoped short name.

public static void With<T>(this T foo, Action<T> action) => action(foo);

no need to yell at people.
Of course, you could always just do that inline...

{
     var s = SomeAwfulEldritchUnspeakablyLongName;
     s.Prop1 = "";
       ... 
     s.PropN = "";
}

I don't think this situation is very common. Usually, I either initialize and modify after newing up, and in the rare cases I can't because it is given to me by IoC, I rather fix those cases by configuration rather than in code.

[CyrusNajmabadi]

Blind in all meanings. I'm so upset I need to explain childish thing to people who pretend to be developers.

To give you some context. I was a member of the C# language design group for over a decade. I helped create C# versions 2 through 8. So i've got a lot of experience and thoughts about this.

First off, your attitude and communication style aren't doing you any favors. At best, they are turning people just not want to listen to you. At worst, it is a violation of the rules of conduct of github and the dotnet foundation. You need to change this, or you will get banned from participating here.

I'm so upset

Then walk away. You're doing yourself no favors by arguing with your emotions. The most gentle way i can put this is that it makes you look petulant and immature. Everyone here is passionate. But people are far more effective when tehy can channel their emotions in a healthy fashion.

Now, ignoring your communication style and just focusing on your opinions:

Only blind people cannot see how SIMPLER code became.

Simplicity is often in the eye of the beholder. One person's simplicity is another's complexity. See, for example, how the C++ community views simplicity, and how that differs from the Go community's views. It is erroneous to assume that your own perspective on what is simple is universally true across the ecosystem and community that C# targets.

For example, some people find things simpler the less they need to look around to pull in necessary context. With with you now have another piece of context you need to understand when examining code. That brings a form of simplicity by allowing you elide, but it adds complexity in makin people having to understand what that elision means.

For example, say i have this:

    this.very.long.statemnet.etc.etc.etc(1, 2, 3, and, it just)[keeps].going
    .method();

versus

    this.very.long.statemnet.etc.etc.etc(1, 2, 3, and, it just)[keeps].going;
    .method();

That's the difference of one token, but it vastly changes the meaning of thins. Previously i could look at the first one and know that .method must extend the previous line. In the new world it could mean two things, and my life is more complex because i have to go figure that out.

--

Finally, please consider that some people here have been doing this a long time, and have a lot of experience trying to figure out the particular pros/cons of a proposal and if they would be net positive for the language. Many will disagree with you. If you want conversations to proceed toward your desired ends you would do well to work with those that disagree, instead of being hostile to them and lashing out.

Cheers, and good luck!

[HaloFour]

@WrongBit

Your example just ridiculous and you really think it proof your words?

If the name of the identifier is so important that you feel that you need to give it a "long meaningful name" then you'd likely not be using a feature like with that gives you no name at all. The beauty of a temporary variable is that you get to make the choice as to how descriptive or terse you want to be.

I don't understand your example of assigning a variable within the with statement. Is that to address my comment about other proposals wanting to actually access the value of the expression from within the block? If so, what's the point of the with statement at all? Just use a normal block and a temporary variable declared within that block.

ATM I see nobody who shows at least one serious argument against.

Ignoring the arguments you don't like doesn't mean that they don't exist. But more critically, you'd need serious arguments for the proposal before the language team would consider adding such a feature. They've clearly known about with since before C# 1.0 was released so it's not like these proposals are showing them something that they don't know about.

As for the tone, I believe that I've been civil towards you even if I've been opinionated towards the feature. I'd appreciate responses in kind. If a rebuttal of your argument can only be seen as "childish" there's little chance that we can actually have a meaningful conversation here.

[WrongBit]

@CyrusNajmabadi
I'm happy somebody experienced come to the thread, but again I see nothing serious why "with" should not be in the language. Your example with "it just)[keeps].going;" is kind of "If you put monkey on the keyboard, your code won't compile". Since when "typo" become argument against features? It's a LANGUAGE, it's IT - serious thing where one character can change everything. Say, "if (a)" against "if (!a)". Why nobody of you ("language design group for over a decade") didn't remove "!" sign? :) Now do you feel how weak your argument? And if you still sure somebody said anything meaningful, just cite that guy. I promise, I carefully consider any argument except "our lazy team just don't wanna bore with that".

[WrongBit]

Thanks to @DanFTRX he found my old request from 2015, because @rushfrisby miss one important thing we can do, having "with" - adding delegate! My sample:

with(var MyVeryDescriptiveVariable = new SomeClass(), OtherVar) {
    .Field1 = .Field2;// it was MyVeryDescriptiveVariable.Field1 = OtherVar.Field2
    .Event += meth();// meth() w/o dot means method from outer scope
    MyVeryDescriptiveVariable.Fun();// ambiguous methods are called with full name
}

Funny, but "serious guys" miss this point with ".Event" and we got half-baked "object initializer", which do NOT allow assign event! My proposal (dotnet/roslyn#6553) fixes this mistake + adds ability to easy assign properties not only after object creation (again limitation!), but anywhere in a program.

[CyrusNajmabadi]

but again I see nothing serious why "with" should not be in the language

I was 100% serious with my critique.

Your example with "it just)[keeps].going;" is kind of "If you put monkey on the keyboard, your code won't compile". Since when "typo" become argument against features?

It's been an argument since v1. We think strongly about these scenarios and the impact it has on customers. Furthermore, the LDM has the absolute final say here. So you need to operate within the perspectives and considerations that hte LDM members have here.

I laid out a trivial example of how this language feature makes things more complex. I now cannot trivially tell what .foo() means anymore. Previously it always meant a invocation off of the previous expression. Now it means an invocation off of the previous expression, if there is one, otherwise it it an invocation off of the innermost contained "with'ed" expression. That is by definition more complex.

i brought this up not to indicate that the feature shuld not be be done, but to help you with perspective. Your perspective is that this is strictly simpler. However, i showed a completely reasonable perspective that demonstrates the additional complexity added. You need to be able to see things through a multitude of perspectives if you want to be able to convince others of the value of these features.

I promise, I carefully consider any argument except "our lazy team just don't wanna bore with that".

Let me make this as clear and as blunt as possible. I decided to reach out to try to help you here. If you're going to behave in a childish and petulant manner, then i'll simply walk away as i have no interest engaging in people who behave this way. You will then lose someone who could have been an advocate for your position.

So ask yourself this:

"What am i trying to accomplish?"

If your goal is to get this language proposal accepted, you are burning bridges and doing a great job to turn people against it entirely based solely on your behavior.

However, if on hte other hand, your objective is to feel good about yourself and think you can browbeat people into supporting you, you can continue in this fashion. But i can assure you, there has been a 0% success rate with getting the language changed by people behaving in this manner in the past.

So what are you trying to accomplish? And how will you change your behavior to have a better chance to get what you want.

--

To help you out, i'm willing to respond one more time. It will be based on the behavior and attitude of your next posts. If they are rude and childish, I'll let you know and simply walk away. If they demonstrate a willingness to engage and work with others in a civil and adult fashion, I'll be happy to keep communicating and sharing my several decades of experience working directly in this space. It's up to you how you proceed.

[mburbea]

Let's assume you did have a With statement. Cyrus's example is interesting as he shows a potential error vector. Let's simplify it

with(f){
     .Prop = SomeChained()
     .Calls();               
}

now if I accidentally introduce a semicolon

with(f){
      .Prop = SomeChained();
      .Calls();
}

These segments may both be valid C#. In the first we are assigning Prop to SomeChained().Calls(), but in the later, we are assigning Prop to SomeChained() and invoking Calls(). This can have wildly differing meaning.
This is alarming and a subtle bug that is hard to spot.

This reminds me of the danger of semicolon completion in javascript, and this would immediately make me not want to use this method at all.

The question when it comes to language feature is not "Why Not?". It needs to be shown as to why it is a large enough value add to be worthwhile. Everyone writes properties, and trimming down the noise to public int Foo=> 7; was considered worthwhile. I can't think of a situation where I would use this beyond the simple initialization (which new T(){...} already handles).

[HaloFour]

@WrongBit

So I must dirt my code with "temporary variable" just to remove necessarity to read long names?

Temporary variables are not dirt. They are the idiomatic way to approach a problem such as this in many languages. They are how with is implemented. Not wanting to use existing features of the language is not a reason to add new features.

[quinmars]

My opinion is that the with feature simply doesn't make the cut in terms of being useful enough to implement. It doesn't solve any problems nor does it appreciably reduce verbosity.

I also don't like the proposed with syntax, but I like the second proposed sytax, because it is an expression, which cannot easily mimiced with a temporary variable. And since it is very similar to the initializer syntax, it'd fit very well into C#.

Here a small example. Suppose we have a class that holds the minimum, maximum and the mean value of a data series plus some decriptive properties.

public class ValueStatistics
{
    public ValueStatisitics() {}
    public ValueStatisitics(IEnumerable<double> series) { ... }

    public double Minimum { get; set; }
    public double Maximum { get; set; }
    public double Mean { get; set; }
    public string ValueName { get; set; }
    public string Unit { get; set; }
    public string Location { get; set; }
}

Now we have a property that returns the statistics for all values in a list:

public IEnumerable<ValueStatistics> StatisticallyValues => AllValues
    .GroupBy(v => v.ValueName)
    .Select(g => new ValueStatistics(g.Select(v => v.Value))
    {
        ValueName = g.Key,
        Unit = g.First().Unit
    });

It turns out that some values are very off and we don't want to consider those outliers in the statistics. So we write a factory method for ValueStatistcs that does exactly this.

public IEnumerable<ValueStatistics> StatisticallyValues => AllValues
    .GroupBy(v => v.ValueName)
    .Select(g => 
    {
        var s = ValueStatistics.WithoutOutliers(g.Select(v => v.Value));
        s.ValueName = g.Key;
        s.Unit = g.First().Unit;
        return s;
    });

So we have to edit several lines (adding s. and replacing , by ;, adding the return, etc.) for a rather simple change: replacing a constructor by a factory method.

With the second proposed syntax it'd be only one or two line changes.

public IEnumerable<ValueStatistics> StatisticallyValues => AllValues
    .GroupBy(v => v.ValueName)
    .Select(g => ValueStatistics.WithoutOutliers(g.Select(v => v.Value)).
    {
        ValueName = g.Key,
        Unit = g.First().Unit
    });

The only problem is that the dot doesn't really fit into the Allman style. On the other hand I have the impression that the with keyword is reserved for the records feature.

[Digitalio1]

@HaloFour @WrongBit @CyrusNajmabadi

My opinion is that the with feature simply doesn't make the cut in terms of being useful enough to implement.

And so, instead of this proposed feature that could be universally used in a number of different contexts, we have object initializers and the new with expression, both of which address this problem (that was deemed unimportant). However, both of these solutions are half-baked and have a number of limitations.

[CyrusNajmabadi]

Didn't anonymous classes do everything that tuples do

No. You can't even specify the type of an anonymous type anywhere (it's anonymous). Literally the opposite of a real expressible type like a tuple.

[Digitalio1]

No. You can't even specify the type of an anonymous type anywhere (it's anonymous)

This limitation was self-imposed. The anonymous types are just regular auto-generated classes under the hood. 🤷

[CyrusNajmabadi]

You keep asking questions and complaining about the answers. I'm not sure what to tell you.

This all started with your assertion that we decided against tuples (which we didn't). It's now morphed to talking about your claim that they do everything that tuples do (they don't).

types are just regular auto-generated classes under the hood. 🤷

And tuples are not that. They are an existing reified type. They are mutable. They are structs. They are binary compatible with other tuples, regardless of member names.

They are very different things. Intentionally.

And, both were things we wanted to do. I still don't know an example of what you were claiming before.

[fandrei]

@CyrusNajmabadi

You seem to be under the impression that language design is some objective process with "right/wrong answers" that can be determined by some simple algorithm.

I never said that there is any perfectly objective process, nor that the process of decision making is simple. Both your assumptions are completely wrong and are based on nothing.

This isn't an argument of facts

Too bad. We are engineers, not art critics. Normally, in engineering and science facts always beat opinions.
I wonder if you even have statistics about the use of language features in real code?

[CyrusNajmabadi]

We are engineers, not art critics.

And, as I said, you seem to be under the impression that language design is some objective process with "right/wrong answers" that can be determined by some simple algorithm.

Language design is a design process. And the design is not in any way objective. The rain we have so many languages is because of the aim to satisfy the subjective needs as much as possible of their creators.

Normally, in engineering and science facts always beat opinions.

See above. These are subjective areas. Opinions are what we have. There is no 'fact' about which opinion is better.

I wonder if you even have statistics about the use of language features in real code?

We have a huge wealth of data.

[Digitalio1]

So, as it was noted, the with keyword was already used, and here is my idea how syntax for this feature can look:

include (obj)
{
    .Property = "Something";
    .foo();
    .AnotherProperty = someVariable;
    .SomeEvent += SomeMethod;
}

The arguments for this feature is that it can cover all the use cases that object initializers and with-expressions cover, plus those use cases that they don't cover.
Any ambiguities or conflicts with other constructs?

[HaloFour]

There wasn't any explanation at all, only distraction.

You not liking the explanation doesn't make it a distraction.

I'm one of the customers, and the language team provides the services. It would be really nice if software vendors remember who pays them money, and that they are not too good to be questioned.

C# is not a piece of contract work. The language designers will answer questions out of courtesy, but they are definitely not obligated to answer anything to whatever you believe your satisfaction to be.

[CyrusNajmabadi]

There wasn't any explanation at all, only distraction.

There was an explanation. You may not have liked the explanation, but that doesn't mean there wasn't one.

[CyrusNajmabadi]

I asked for a single real example of code.

Yes. And I chose to not take my time to do that, and I explained why. We are not beholden to you to provide you the answers in only the way you accept. This is a discussion forum where we are free to respond how we want.

So, you're too good for your decisions to be questioned. Ok.

You are welcome to question it. But you are owed nothing, including answers in a speech fashion that will appease you. Everyone here is free to answer as they please (within the bounds of the code of conduct)

As several people have stated so far, you are getting responses that are in line with the tone that you presented. As I mentioned multiple times, you win more with honey than vinegar. You chose to ignore that, which is why people have not been willing to do any more than they think is necessary when responding to you.

At any point you can change how you're acting here. I expect if you do so, you'll see people respond in kind. But if you continue to converse belligerently, then no one is going to go out of their way to help.

[CyrusNajmabadi]

I'm one of the customers, and the language team provides the services.

That does not include any sort of obligation to you. It does not include an obligation to work on your behalf.

It would be really nice if software vendors remember who pays them money

This is an open source project. If you want to hire me, then I work for you. But right now, I do not, and I (and everyone else) has no obligation to you whatsoever.

Note that we have great discussions with thousands of other devs. And we routinely do put in a lot of effort with them. We do that not because those devs pay us money (hint, the don't). We do this because those other devs are great people who converse awesomely, and contribute to healthy discussions and awesome discourse.

Had you done the same, you would have found the language designers and community treating you in kind. But if you come in antagonistic and aggressive, you'll find that virtually everyone will not give anything in return.

Again, the ball is on your court on how you want to behave. Virtually everyone else does so in a constructive fashion. If you choose not to, then that's on you. :-)

[siegfriedpammer]

I have used VB and Delphi in my career and hardly ever used "with" in those languages and never felt the need to have it in C#. If you do some research what Delphi developers think about "with", you will find a lot of people arguing against it. They mention that it makes the following things harder:

• reading the code
• maintaining it
• debugging it

The only thing "with" makes easier is writing code. But as we all know, code is read far more often than it is written. There is even a famous joke about Java: "write once, debug anywhere". With the advent of AI tools readability and maintainability become even more important to make it easy to verify correctness.

Shorter/terse code is usually not easier to read.

The existing "with" expressions and object initializers have the same problem when debugging. You cannot really inspect the object being constructed and you cannot break execution in the middle of the expression (granted, the latter is a tooling issue, which could be fixed by emitting different sequence points). I frequently have to fall back to temporary variables anyway.

Programming language design should always learn from the mistakes of the past/of others.

Some blogs/articles from the Delphi world:

• https://hallvards.blogspot.com/2004/08/with-statement-considered-harmful.html
• https://blogs.embarcadero.com/delphi-with-statements-and-local-variables/
• and probably more, but I don't have time now...

Apparently, there even have been requests to remove the "with" statement from the Delphi language (see the second link).

For C# it is impossible to remove a language feature. The C# designers do not want to make the same mistakes as Python or Swift, where one major version of the language was completely different from the next, so you have to manually or semi-automatically convert your code. This is also the reason why new language features are not added on a whim, but all scenarios, pros and cons are carefully considered and evaluated.

The C# LDT is doing a great job. So, when can we get DUs? Just kidding wink wink

[AndersKehlet]

With statements add an object in the direct scope, but offer no way to differentiate between an operation on the object part of the with or the self object of the current method.

That seems very specific to Delphi's implementation, rather than some general problem with 'with'.

Shorter/terse code is usually not easier to read.

This is kind of a non-statement. Less terse code is not necessarily easier to read either. There's a goldilocks zone of terseness. Personally I prefer F#'s terseness over C#, but I can live with either.