&&= and ||= #397

TonyValenti · 2017-04-01T11:32:36Z

Hi All,
I would like to request that C# add &&= and ||= operators so I can write code as follows:

var ret = false;
ret ||= TryMethod1();
ret ||= TryMethod2();
ret ||= TryMethod3();

The text was updated successfully, but these errors were encountered:

AdrienTorris · 2017-04-01T12:33:00Z

What behavior do you want for the operators &&= and ||= ?
Your code is just like :
var ret = TryMethod3();

Pzixel · 2017-04-01T12:36:55Z

@TonyValenti what's wrong with

var ret = TryMethod1()
|| TryMethod2()
|| TryMethod3();

?

And of course you know, && and || are lazy operators and they halt when result cannot be changed due to absorption with true/false constant.

You can write

var ret = false;
ret |= TryMethod1();
ret |= TryMethod2();
ret |= TryMethod3();

It's completely valid in C#. But your proposition just doesn't make sense.

miloush · 2017-04-01T12:38:20Z

@AdrienTorris it's not, if any of the previous method returns true, I assume that TryMethod3() would not be called.

drewnoakes · 2017-04-01T13:14:23Z


Edit: My mistake.

miloush · 2017-04-01T13:48:32Z

@drewnoakes I might expect that from something like ??= but not &&= or ||=

drewnoakes · 2017-04-01T13:52:20Z

Derp. You're right. That's what commenting from a sofa looks like :)

I was wondering about ??= the other day, then saw this. Brian conflated the two.

TonyValenti · 2017-04-01T13:54:39Z

+1 for ??=

On Sat, Apr 1, 2017 at 8:52 AM Drew Noakes ***@***.***> wrote: Derp. You're right. That's what commenting from a sofa looks like :) I was wondering about ??= the other day, then saw this. Brian conflated the two. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#397 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AM-qVrdhfhc1UN-0KvT7DcUIzIAldD5Kks5rrlaXgaJpZM4MwdeE> .

-- Tony Valenti

jnm2 · 2017-04-01T15:14:13Z

??= is by far the most common thing I do (return x ?? (x = CalcX())) but it just feels wrong not to have &&= and ||= as well.

CyrusNajmabadi · 2017-04-01T18:37:47Z

I would be willing to champion this. But i haven't had time to work on my other championed features yet :-/

drewnoakes · 2017-04-01T21:35:18Z

Existing issue #34 tracks support for null-coalescing assignments via ??=.

DavidArno · 2017-04-02T08:01:15Z

I'm confused by this request (especially by the suggestion that @CyrusNajmabadi would consider championing it), as I don't see how it would achieve anything that isn't already offered by the language.

As @Pzixel points out, the OP can achieve the requested functionality in his example, using:

var ret = false;
ret |= TryMethod1();
ret |= TryMethod2();
ret |= TryMethod3();

So what would the ||= operator bring to the language?

yaakov-h · 2017-04-02T08:24:21Z

It wouldn't always evaluate the right-hand side.

DavidArno · 2017-04-02T09:07:10Z

@yaakov-h,

Ah, I get you. Again as @Pzixel suggested, this can already be achieved via:

var ret = TryMethod1()
    || TryMethod2()
    || TryMethod3();

And if the two tests need to occur with some other statement between them, then the two results have different meanings, so should have different variable names:

var result1 = TryMethod1();
DoSomething();
var result2 = result1 || TryMethod2();

But I know some folk like to overload their variables with multiple meanings, so I can see why ||= would appeal to those folk.

yaakov-h · 2017-04-02T09:10:37Z

I agree that it can already but achieved, however I also see some value in breaking the intermediate result out into a variable.

This allows for easier debugging, and naming of the variable can aid in readability and intrinsic documentation.

DavidArno · 2017-04-02T09:19:38Z

This allows for easier debugging, and naming of the variable can aid in readability and intrinsic documentation.

Indeed, which is why it's a good idea to avoid using +=, -=, |= etc and to instead assign the result to a new variable, for "naming of the variable can aid in readability and intrinsic documentation."

jnm2 · 2017-04-02T13:03:10Z

@DavidArno This works especially well with if statements. I treat mutable variables like this as builders. The meaning doesn't change during construction.

CyrusNajmabadi · 2017-04-02T19:27:03Z

&&= and ||= are good for general accumulation-style algorithms (just like += and the like). ??= is good for algorithms that want to lazy initialize something only when necessary. i.e.:

// making a connection is expensive and should be deferred until necessary.  once made, the
// same connection should be used from that point on.
SqlConnection connection = null; 

foreach (var blah in whatever)
{
    // lots of logic
    ...
    if (yupINeedConnection)
    {
        connection = connection == null ? new SqlConnection() : connection; // or
        connection = connection ?? new SqlConnection();
        // use connection.
        ...
    }
}

This is more nicely written as:

// making a connection is expensive and should be deferred until necessary.  once made, the
// same connection should be used from that point on.
SqlConnection connection = null; 

foreach (var blah in whatever)
{
    // lots of logic
    ...
    if (yupINeedConnection)
    {
        connection ??= new SqlConnection();
        // use connection.
        ...
    }
}

&&= and ||= are generally useful while looping, and while you need to process every element, but where you want to accumulate some final boolean value. For example:

var runAgain = null;

foreach (var token in this.DescendentTokens())
{
     // do a lot of stuff.

     runAgain = runAgain || ComputeSomethingExpensive(something);
}

This is nicer as:

var runAgain = null;

foreach (var token in this.DescendentTokens())
{
     // do a lot of stuff.

     runAgain ||= ComputeSomethingExpensive(something);
}

Basically, the operators just simplify general lazy/accumulation patterns that do show up elsewhere.

Is this super important? Definitely not. But it's nice and consistent, and likely easy to slot in.

Basically, any time the language has an operator that you could do: "x = x op y", then it would be nice to have a "x op= y" version for uniformity.

HaloFour · 2017-04-02T19:47:05Z

I can't find it at the moment but I recall &&= and ||= coming up during another conversation and Mads commenting that he didn't like the idea. Of course things always change...

jnm2 · 2017-04-02T22:16:36Z

@CyrusNajmabadi With the loop, wouldn't you prefer to break rather than redo the same truth test for the rest of the loop?

CyrusNajmabadi · 2017-04-02T22:48:44Z

@jnm2 Only if the goal was to determine if we needed to set "runAgain". But often you may still have other work you need to do with the rest of the items in your collection.

Hence the " // do a lot of stuff." line. The implication here is that it's important that we process all the items. But that we only want to ComputeSomethingExpensive as long as it is returning false. once it returns 'true' once, we don't need to again.

DavidArno · 2017-04-03T07:05:30Z

@CyrusNajmabadi,

Your example highlights different styles of programming creating different syntax needs. Your example:

foreach (var token in this.DescendentTokens())
{
     // do a lot of stuff.

     runAgain ||= ComputeSomethingExpensive(something);
}

would end up something like the following in my hands:

foreach (var token in this.DescendentTokens())
{
    DoALotOfStuffWithToken(token);

    if (expensiveComputationProvider.RunAgain)
    {
        ...
    }
}

I'd expect the state of whether runAgain is true to be abstracted away to both aid testing and to keep the method focused on its job, rather than having to manage state too.

However, I like the idea of ??=, as that would tidy up lazy properties:

bool RunAgain => (_expensiveComputationResult ??= ComputeSomethingExpensive()).RunAgain;

And if ??= were added, then the lack of ||= and &&= become a strange inconsistency in the language syntax.

But seriously, could we please complete pattern matching and add match, records and DU's to the language before we start doing the little "nice to have" stuff like this? Pretty please?

orthoxerox · 2017-04-03T08:22:37Z

@DavidArno this little nice to have stuff could probably be done by the community, if the LDT ever decides to relax their iron grip on the development reins.

CyrusNajmabadi · 2017-04-03T17:26:31Z

I'd expect the state of whether runAgain is true to be abstracted away to both aid testing and to keep the method focused on its job, rather than having to manage state too.

Managing algorithmic state is totally fine for a function to do IMO :)

I mean, do you not accumulate values in your functions ever? Do you never use ++ anywhere? After all, you could take that incremented local state and put it in some other "computation-provider" struct/class.

Regardless, people have state in functions today. All the time. I see nothing wrong with making working with that state more pleasant.

--

But seriously, could we please complete pattern matching and add match, records and DU's to the language before we start doing the little "nice to have" stuff like this? Pretty please?

There is no way that i'll be able to champion any of those things to hte language. I do not have the time, and i'm completely booked on working in the IDE space and on things like IOperation. But, i can potentially squeeze in time for language features that i think just make things more pleasant at low cost. Hence why i'd be willing to champion it. If i don't champion it, it just means that it doesn't get done. It doesn't mean those other things get done.

CyrusNajmabadi · 2017-04-03T17:28:29Z

@orthoxerox At the end of the day, the LDM is going to decide what does/doesn't go into the language. Just consider how many proposals are out there. Consider how many of them you probably don't like :) Now consider what sort of language you have if there isn't something preventing all those language changes from just getting added to the language whenever someone in the community wants it. :)

DavidArno · 2017-04-03T18:16:43Z

@CyrusNajmabadi

I mean, do you not accumulate values in your functions ever? Do you never use ++ anywhere?

I'd be lying if I said I never used such features. But it is incredibly rare that I do. Different approaches...

DavidArno · 2017-04-04T12:10:48Z

@CyrusNajmabadi

At the end of the day, the LDM is going to decide what does/doesn't go into the language. Just consider how many proposals are out there. Consider how many of them you probably don't like :) Now consider what sort of language you have if there isn't something preventing all those language changes from just getting added to the language whenever someone in the community wants it. :)

Exhibit A: out/is var and scope leakage.

Near-universally disliked by the community, but we got it anyway. Clearly the LDM team doesn't protect us from features we don't like...

jnm2 · 2017-04-04T12:33:10Z

GitHub is not a large percentage of the entire community from what I gather.

DavidArno · 2017-04-04T12:50:58Z

@jnm2,

Ah yes, I forgot that significant part of the "community" that communicate with the LDM in secret... 😆

jnm2 · 2017-04-04T13:57:02Z

@DavidArno Who says the communication is secret?

orthoxerox · 2017-04-04T14:33:50Z

@DavidArno Yes, you forgot about enterprise customers that ask for features through their account managers.

DavidArno · 2017-04-04T15:09:39Z

@jnm2,

That communication takes place (such communications were used as a major argument for out var scope leakage, for example), yet they aren't public. So they are secret.

@orthoxerox,

And that, I feel, is the real reason behind the LDT keeps a vice-like grip on new features. Those enterprise customers would be less than happy if they suddenly had to argue their case with the community.

gafter · 2017-04-04T18:16:44Z

This feature request is already an open question as part of an existing championed proposal, which has been triaged by the LDM for possible inclusion in some minor or major release.

drewnoakes · 2017-04-05T12:33:55Z

@gafter, I may be mistaken but I think this issue differs. It's referring to logical &&= and ||=, not null coalescing assignment via ??=.

GeirGrusom · 2017-04-05T12:43:06Z

@drewnoakes It's ~~almost~~ the same thing:

a &&= b = a = a && b
a ||= b = a = a || b
a ??= b = a = a ?? b

drewnoakes · 2017-04-05T13:48:15Z

@GeirGrusom, they're similar, but not the same.

There's a separate issue tracking ??=: #34

GeirGrusom · 2017-04-06T05:51:26Z

How does this issue differ really? The difference between ??= and &&= is as big as the difference between ||= and &&=. They only differ in what value they compare against.

gafter · 2017-04-10T16:33:19Z

@gafter wrote:

This feature request is already an open question as part of an existing championed proposal, which has been triaged by the LDM for possible inclusion in some minor or major release.

@drewnoakes wrote

@gafter, I may be mistaken but I think this issue differs. It's referring to logical &&= and ||=, not null coalescing assignment via ??=.

Quoting from https://github.com/dotnet/csharplang/blob/master/proposals/null-coalecing-assignment.md :

Unresolved questions

Requires LDM review

Should we also support &&= and ||= operators?

Does that look different to you?

drewnoakes · 2017-04-10T17:24:41Z

@gafter perhaps you should close this as a duplicate in that case.

gafter · 2017-04-10T17:44:46Z

@drewnoakes This is a discussion issue. The other is a tracking issue for a related championed proposal that may come to include this feature. I don't expect we'll be closing discussion issues.

Perksey · 2020-07-07T19:01:44Z

Wow it's been a hot minute since this has been brought up again but seeing as the null coaelescing operator proposal is pretty much done without these operators included, will this proposal ever be brought back up in an LDM or will it continue to live inconclusively ever after?

CyrusNajmabadi · 2020-07-07T19:04:04Z

will this proposal ever be brought back up in an LDM or will it continue to live inconclusively ever after?

It may be brought up in the future if any LDM members wishes to champion it.

333fred · 2020-07-07T19:41:26Z

It was championed, and explicitly rejected by LDM: #1718

Perksey · 2020-07-07T19:42:45Z

Gotcha, should these issues be closed then to prevent further confusion?

…

On Tue, 7 Jul 2020 at 20:41, Fred Silberberg ***@***.***> wrote: It was championed, and explicitly rejected by LDM: #1718 <#1718> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#397 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVEYI4HXLZ4WK3O3ZKZEMDR2N27NANCNFSM4DGB26CA> .

333fred · 2020-07-07T19:43:25Z

I'll leave the championed issue open so that it appears when people search, but I'm going to close this one.

Perksey · 2020-07-07T19:47:13Z

Note that the description of the champion issue doesn’t currently specify that the proposal is rejected, and may not see the small comment that specifies that it is rejected.

…

On Tue, 7 Jul 2020 at 20:43, Fred Silberberg ***@***.***> wrote: Closed #397 <#397>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#397 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACVEYI6J3WGS772Z25WUZLTR2N3G3ANCNFSM4DGB26CA> .

UdderlyEvelyn · 2022-01-17T22:51:52Z

__result is a bool coming in by ref that needs to be changed but also consider its original value in the end value.. we ended up having to write this:

__result = __result && SomeMethod();

Would have been nice to write:

__result &&= SomeMethod();

I realize this is niche, but it.. is a legitimate use case! Heh.

gafter added Discussion Feature Request labels Apr 4, 2017

333fred closed this as completed Jul 7, 2020

CyrusNajmabadi mentioned this issue Mar 7, 2022

bool type &= should have a short-circuit-evaluating form. #5894

Closed

synercoder mentioned this issue Dec 21, 2022

Champion: "&&= and ||= assignment operators" #1718

Closed

5 tasks

&&= and ||= #397

&&= and ||= #397

Comments

TonyValenti commented Apr 1, 2017

AdrienTorris commented Apr 1, 2017

Pzixel commented Apr 1, 2017 • edited Loading

miloush commented Apr 1, 2017

drewnoakes commented Apr 1, 2017 • edited Loading

miloush commented Apr 1, 2017

drewnoakes commented Apr 1, 2017

TonyValenti commented Apr 1, 2017 via email

jnm2 commented Apr 1, 2017

CyrusNajmabadi commented Apr 1, 2017

drewnoakes commented Apr 1, 2017

DavidArno commented Apr 2, 2017

yaakov-h commented Apr 2, 2017

DavidArno commented Apr 2, 2017 • edited Loading

yaakov-h commented Apr 2, 2017

DavidArno commented Apr 2, 2017

jnm2 commented Apr 2, 2017

CyrusNajmabadi commented Apr 2, 2017 • edited Loading

HaloFour commented Apr 2, 2017

jnm2 commented Apr 2, 2017

CyrusNajmabadi commented Apr 2, 2017 • edited Loading

DavidArno commented Apr 3, 2017

orthoxerox commented Apr 3, 2017

CyrusNajmabadi commented Apr 3, 2017

CyrusNajmabadi commented Apr 3, 2017

DavidArno commented Apr 3, 2017 • edited Loading

DavidArno commented Apr 4, 2017 • edited Loading

jnm2 commented Apr 4, 2017

DavidArno commented Apr 4, 2017 • edited Loading

jnm2 commented Apr 4, 2017

orthoxerox commented Apr 4, 2017

DavidArno commented Apr 4, 2017

gafter commented Apr 4, 2017

drewnoakes commented Apr 5, 2017

GeirGrusom commented Apr 5, 2017 • edited Loading

drewnoakes commented Apr 5, 2017

GeirGrusom commented Apr 6, 2017

gafter commented Apr 10, 2017

Unresolved questions

drewnoakes commented Apr 10, 2017

gafter commented Apr 10, 2017

Perksey commented Jul 7, 2020 • edited Loading

CyrusNajmabadi commented Jul 7, 2020

333fred commented Jul 7, 2020

Perksey commented Jul 7, 2020 via email

333fred commented Jul 7, 2020

Perksey commented Jul 7, 2020 via email

UdderlyEvelyn commented Jan 17, 2022 • edited Loading

Pzixel commented Apr 1, 2017 •

edited

Loading

drewnoakes commented Apr 1, 2017 •

edited

Loading

DavidArno commented Apr 2, 2017 •

edited

Loading

CyrusNajmabadi commented Apr 2, 2017 •

edited

Loading

CyrusNajmabadi commented Apr 2, 2017 •

edited

Loading

DavidArno commented Apr 3, 2017 •

edited

Loading

DavidArno commented Apr 4, 2017 •

edited

Loading

DavidArno commented Apr 4, 2017 •

edited

Loading

GeirGrusom commented Apr 5, 2017 •

edited

Loading

Perksey commented Jul 7, 2020 •

edited

Loading

UdderlyEvelyn commented Jan 17, 2022 •

edited

Loading