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.

[WrongBit]

@HaloFour Related "INotifyPropertyChanged" - just trust me, 10 years later people will kill you for any mention of that ugliest "programmer's invention" (like now for 'goto'). Sorry for offtop.

[YairHalberstadt]

@WrongBit

Only blind people cannot see how SIMPLER code became. Blind in all meanings. I'm so upset I need to explain childish thing to people who pretend to be developers.

Can you please try and avoid being impolite when discussing things here. It is making this conversation unpleasant.

[DanFTRX]

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.

[HaloFour]

@fandrei

if you think that this feature is just not high enough in the list of priorities

A non-championed proposal isn't on a list of priorities. Without language team members willing to champion a design through the process, a proposal is not going to happen. As it stands, that is the status of this proposal.

[CyrusNajmabadi]

You probably should try to explain better,

I'm not sure how to explain it better. Without this feature, the syntax is clear and means only one thing, regardless of what could have come before. With thsi feature it could mean multiple things and now takes extra effort to determine that meaning. That extra effort adds complexity in an area i don't feel is worthwhile.

[CyrusNajmabadi]

because previous 2 were not enough

You're welcome to feel that way. We don't agree. Disagreements are normal in subjective design spaces :)

[CyrusNajmabadi]

Just don't make up excuses

No excuses were 'made up'. I gave the reasons i believe this feature is a net negative. I listed them clearly. Currently there are at least 5 problems as i see it, and very little upside.

why the feature is bad.

The reasons i gave are why i think the feature should not be done. I don't know what else to tell you on that.

Because when I see incorrect arguments,

How can a subjective feeling on relative value of a feature vs relative drawbacks be 'incorrect arguments'?

I feel an urge to refute them.

How are you refuting subjective views on value/problems of a lang feature proposal? What does that even mean?

[CyrusNajmabadi]

@fandrei 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. That's not the case. This is a design process. It is subjective. And it is run by a group (myself included) that takes all our experience and all that subjective assessment of the space, and uses that to try to determine a path to take.

In several posts you've intimated that this is some sort of 'argument', where there is some series of rational, logical, steps that leads to one unescapable conclusion. That is absolutely not what is going on here. This isn't an argument of facts (though facts can be presented if valuable). This is a discussion of ideas. It is used to sway opinions. Ultimately, it either sways the mind of an LDM member, or it doesn't.

Currently, as the LDM member interacting with this proposal, i can say that not only has it not swayed me, it has provided more information to indicate to me that it would be a mistake to take this on.