foreach?

[TonyValenti]

It would be great to have a foreach? construct that would skip if the enumerable was null.

IEnumerable<object> Source = null;

foreach?(var item in Source){
  //This won't cause an error.
}

[MgSam]

Not as concise, but Enumerable.Empty works perfectly.

IEnumerable<object> Source = null;

foreach(var item in Source ?? Enumerable.Empty<object>()){
  //This won't cause an error.
}

[MkazemAkhgary]

usually I throw exception if source is null but sounds nice.

[scalablecory]

I have an extension method that is simply MgSam's code, so I do:

foreach(var item in Source.Touch())

(*nix people will recognize touch)

This change wouldn't be a big win but I do it often enough that I wouldn't say no to a foreach that treats a null collection as one with zero elements.

[TahirAhmadov]

I would recommend a more meaningful word (borrowing from *nix is almost guaranteed to be anything but that). Something like EmptyIfNull perhaps?

[TonyValenti]

I actually already have an EmptyIfNull extension method that I use. :-)

[jnm2]

I'd hate to see a language construct that encourages people to conflate 'null' and 'empty' worse than they already do. Some people would see it as a "safer" foreach and use it defensively, not realizing that the NRE was actually better at preventing state corruption. (Always fail as early and as loudly as possible when the programmer's assumptions are violated- that's never a recoverable scenario.) Far better still, ArgumentNullException or a separate code path to deal with the separate semantics. If 'null' and 'empty' happen to be semantically equivalent in a certain case, make that explicit using if before the foreach.

[MkazemAkhgary]

@jnm2 alright then, how does if(x is {} y) makes you feel like, it makes me vomit 😭

[scalablecory]

@jnm2 there is only so much benefit to catering to green devs, when it is at the expense of everyone else.

[CyrusNajmabadi]

I'd hate to see a language construct that encourages people to conflate 'null' and 'empty' worse than they already do

I disagree. I've used several languages that are lenient with nil-like constructs, and it honestly feels fine to me when I use them. For better or worse, nulls permeate the entire ecosystem, and making them painful to deal with just means pain and aggravation when coding. For example, before ?. and ?? code was so much less pleasant to write and maintain. I'm not against just accepting that nulls exist, and giving simple ? mechanisms to deal with them, instead of having to go full hog into other forms.

That said, for this specific case, it does seem like there are acceptable existing workarounds. So my support of this particular situation is pretty low.

@jnm2 there is only so much benefit to catering to green devs, when it is at the expense of everyone else.

This doesn't have anything to do with devs being green or not. It has to do with the pervasiveness of 'null' and the cost of the excess ceremony necessary to deal with it. It was precisely this that led to the introduction of things like the null-propagation operator, and it's why there has been so much effort in C# 8 toward better analysis and exposure of null handling. Better handling of null is a significant feature for most C# devs, not just 'green' ones.

[CyrusNajmabadi]

not realizing that the NRE was actually better at preventing state corruption.

This is only true if you equate null with state corruption. Whereas, for an enormous number of apis and domains, it's a completely legal and expected value representing non-corrupt state.

This is the crux of the problem. There is no one true ideology around 'null'. At least not in .net/c#. And even if we could pick an ideology that people liked for it, it wouldn't likely never get enough widespread adoption until we got to a point of everything being rewritten (at which point, we'd likely be using a different language anyways). The reality of the situation is that null exists. Is here to stay. And is enormously pervasive. We can't avoid any of that, or wish it away. As such, the language embraces that and accepts that being opinionated against that fact only serves to cause people more pain than good. It's also why, when we have accepted and worked to improve things in this area, the response has been nearly universally positive, with huge adoption across the ecosystem of these new constructs due to their value and convenience so outweighing these sorts of concerns that have been raised.

[jnm2]

@CyrusNajmabadi

This is only true if you equate null with state corruption.

I do not equate null with state corruption. Nothing could be further from accurate. null for a collection means "take a different approach" at least as often as it means "treat as an empty collection." Right now you have to encode your expectations explicitly. And if you fail to be explicit, that's when NRE (or a similar exception meaning "the programmer did not plan for this") is crucial. I reject the notion that it's good to blur that line because it's already enough of a pit of failure.

You could argue that foreach? is explicit enough, but like I said, that just encourages people to default to foreach? rather than foreach and the signal becomes worthless.

[scalablecory]

The line is already blurred, you can't un-blur it. I'd even argue that the blurriness necessary: .NET putting everything on the heap makes null the most intuitive way to avoid unwanted GC pressure for oft-empty collections.

[CyrusNajmabadi]

I reject the notion that it's good to blur that line

I disagree, purely because (IMO), the thought experiment has been tried elsewhere and i've personally not found it to be an issue. Indeed, the blurring of the lines is what transforms it from a "pit of failure" to a totally fine programming paradigm :) In other words, it's precisely because null has to be handled so differently that it becomes a pit of fail.

[CyrusNajmabadi]

Note: i don't forsee a lot of value coming from a huge back and forth on this :) I understand and can respect your position. Needless to say, i think making null handling more pleasant is valuable. but i also think the primary cases have already been handled well, and not much more work here is necessary at the language level. (Although, i do really think an await? feature would be nice, and would be personally preferred before a foreach? feature.

[DavidArno]

@MkazemAkhgary,

How can the follow do anything but fill you with joy? 😆

foreach (var item in Source is {} source ? source : Enumerable.Empty<object>())
{
  //This won't cause an error.
}

[yaakov-h]

What's the actual motivation for this?

• If it's symmetry with the if? and await? proposals, then as much I don't like it, it makes sense to have as a cohesive group of language features.

• If it's because you keep getting NREs when foreach-ing, then the warnings from [Non-]Nullable Reference Types should stop you doing that.

• If it's because your codebase regularly uses null interchangeably with empty-enumerable, I'd argue that you just shouldn't do that.

I'm mostly in agreement with @jnm2 - there's a big difference between "this box has no items in it" and "there is no box". Null may be pervasive and here to stay, but that doesn't mean we should be using it everywhere, either.

[CyrusNajmabadi]

If it's because your codebase regularly uses null interchangeably with empty-enumerable, I'd argue that you just shouldn't do that.

What's the argument for not doing that? It seems reasonable to me.

Note: this is one of those areas where the language/APIs incestuously impact each other. If, for example, the language had been null-tolerant here from the beginning (like you see in some other languages), then it would likely be the case that many APIs would use null routinely for collections. But, it doesn't, so it's less common.

there's a big difference between "this box has no items in it" and "there is no box"

That's domain specific. For many domains it suffices to mean "i don't have any items". This is why, for example, APIs like "string.IsNullOrEmpty" exist. Certainly, one could make the same argument "there's a big difference between no string and an empty string", and that's certainly true some of the time. But for a large set of cases, it's not actually a big difference at all.

Given that .net has not at all really pushed that there's deep difference, and given that many out there are fine conflating, and given that other languages/domains certainly do this sort of conflation, i don't think it's reasonable to state that everyone has to think there is a large difference here.

Indeed, as i mentioned earlier, i think one of the huge pain points around null is precisely that it blows up on you in domains where people don't need or want it to blow up. For example, when i did Objective-C development, nil wasn't really painful. That's because the majority of the language, APIs, and patterns worked well with it. As such, coding was pleasant without having to continually think about hte distinction, and without having to worry about code blowing up as much as i need to with .Net/C#.

It's not wrong to want to move toward patterns that try to remove null entirely, but it's also not wrong to try to make the experience better when working in domains where null is common.

[YairHalberstadt]

@huysentruitw
At which point why not just do

if(source != null)
    foreach (var item in Source) {...}

[huysentruitw]

because of nesting of course.

we also didn't need ?? throw new Exception() or catch () when (), but they're damn practical when you need them.

[YairHalberstadt]

But your syntax is no more concise, and is adding a completely new syntactic structure to the language.

[huysentruitw]

But you don't have to explain anyone what it does... foreach? () on the other hand is very confusing, it could also mean the foreach skips elements that are null f.e.

[YairHalberstadt]

Neither do you have to explain an if statement to anyone.

[huysentruitw]

And we're back to #1081 (comment)

[YairHalberstadt]

What I'm saying is when is no better than if. So there might or might not be point introducing a foreach? syntax, but there's definitely no point introducing a when syntax, even if it arguably better than foreach?

[DanFTRX]

I would say that when would avoid an extra nested scope, so it is better than if....

[markusschaber]

The line is already blurred, you can't un-blur it. I'd even argue that the blurriness necessary: .NET putting everything on the heap makes null the most intuitive way to avoid unwanted GC pressure for oft-empty collections.

Then: Do we need some syntactic sugar for Array.Empty<T>() or Enumerable.Empty<T>(), to make it easier and more intuitive to give an empty list? Maybe [] as in Python, just with automatic type deduction?

[markusschaber]

we also didn't need ?? throw new Exception() or catch () when (), but they're damn practical when you need them.

I don't want to nitpick here, but catch () when () actually has semantic differences compared to always catching, and then examining the exception and conditionally rethrowing. There was no way to achieve those semantics using C# (in contrast to VB.NET (and the CLR itself) which had this possibility since ever. :-) ).

(Another use case stems from the fact that it can be abused for side-effects in the when condition, e. G. by a logging function which always returns false.)

Note that this is not intended as a counter-argument of conditional foreach...

[VBAndCs]

Another alternative:

foreach(var item in Source??){
  //This won't cause an error.
}

[HaloFour]

Maybe with list literals and target typing:

foreach(var item in Source ?? []) {
  //This won't cause an error.
}

[Zetanova]

Why not use the bang operator as an explicit declaration "it's not null or it should be empty"

foreach(var item in Source!.Where(n => n.Value == 1)){
  //This won't cause an error.
}

foreach(var item in Source!){
  //This won't cause an error.
}

foreach(var item in Source?.Where(n => n.Value == 1)!){
  //This won't cause an error.
}

[HaloFour]

Why not use the bang operator as an explicit declaration

That is already legal syntax as the bang operator is the null forgiving operator which silences possible null dereferencing warnings.

[Zetanova]

Yes and it still generates the wonderful ArgumentNullException

I know currently the band operator is a no-op and only used as null forgiving operator.
The extended usage could simply be to declare the null enumeration as empty.

Legacy could wont break and code that uses it explicitly would have the new behavior

The c# 9 current generated code:

IEnumerator<object> enumerator = values.GetEnumerator();
        try
        {
            while (enumerator.MoveNext())
            {
                object current = enumerator.Current;
            }
        }
        finally
        {
            if (enumerator != null)
            {
                enumerator.Dispose();
            }
        }

With the bang "null forgiving operator" operator this could look like

if (values != null)
{
    IEnumerator<object> enumerator = values.GetEnumerator();
    try
    {
        while (enumerator.MoveNext())
        {
            object current = enumerator.Current;
        }
    }
    finally
    {
        if (enumerator != null)
        {
            enumerator.Dispose();
        }
    }
}

But at the end it is not so important, only a bit annoying.

I had a view month ago an other idea with a band-sharp to add custom behavior operator in a project,
made a bit research on it but did not invest more.

This would be then like

foreach(var v in values!#empty) 
{
}

But the better use case would be for parameters to add custom validators or transformations

void MyFunc(string currency!#EUR) 
{
}

//some extension method
public static string EUR(this string? s) 
{
   if(string.IsNullOrEmpty(s))
      return "EUR";

   if(s.Length != 3)
      throw new ArgumentException();
   
    return s.ToUpper();
}

[legistek]

I'm baffled why anyone would oppose this. The arguments against it seem to be nothing but pedantic and fall apart when you cosnider that using doesn't throw on a null. If you can give me a substantive reason for treating those differently you're more imaginative than I am.

I would fully support simply changing the behavior for foreach with no syntactic modification, though many will protest that this is a "breaking" change because - I guess - we should be concerned with people who rely on the throwing of exceptiosn for the proper control flow of their code (those people deserve what they get, IMHO). But for anyone to ignore or dismiss the idea of adding a simple one-character syntactical option that would not only save time but help eliminate countless bugs, that to me reflects being completely out of touch with the realities of commercial software development.

[CyrusNajmabadi]

do you really think it's a better use of all y'all's resources to reprogram the compiler

Yes. 100%. Because now we have a broad feature that provides value to the entire ecosystem, for an enormous number of cases. Versus a niche feature that solves exactly one thing for one narrow use case. :)

This is almost always a better use of our time, and it's def what we get constant feedback from customers on :)

[legistek]

Alright. Well I'm definitely in over my head at this point. I dropped compilers 101 in college for good reason. I would certainly opt for ?? [] if that was the best alternative and I knew it wouldn't create a new collection on every iteration.

[jnm2]

Also, if someone was already doing ?? Array.Empty<T>(), they'll get an IDE suggestion to switch to ?? [].

[TahirAhmadov]

It would be helpful that quick fixers explain the performance implications of these suggestions

[jnm2]

So far, I think the suggestions will all at least be as good if not better.

[TonyValenti]

I'm really surprised that \e was accepted as a QOL enhancement but this was not. This seems much more useful to many more situations than \e.

[CyrusNajmabadi]

\e has not been accepted. :-)

[HaloFour]

I'd suggest that adding a new escape sequence is several orders of magnitude less controversial or involved than a new form of control statement.

[CyrusNajmabadi]

That too. Also, the foreach? proposal doesnt even cover the main use case I care about. Like what to do with a 'default' ImmutableArray :-)

I also think ?? [] is fine as workaround (something I think \e is lacking).

\e also has no cost with things like our syntax model, etc. It's genuinely probably less work than the time to get it through CI.

Note: I don't have an expectation it will be accepted (and I said exactly as much). But I'm willing to see what the design team thinks.

[piju3]

The nitpicking about not confusing null and empty seems unreasonable when ?. ?? ??= are all in the language. Null forgiveness is a clearly established pattern now that is used everywhere, and the lack of foreach? just seems like an inconsistency.

"This object may or may not have a value, and I want to use it" is hardly a narrow use case.

If anything, it seems to me having this operator would actually help establish a distinction, because it would let you use both null and empty collections without inconveniencing the people who actually want to use the values contained in them.

[jnm2]

It's actually uncertain that the ?? [] optimization will be applied in the future except to a few vetted types, due to the risk that calling GetEnumerator and MoveNext once on the transient empty collection would have global side effects that would be unexpectedly missing. See dotnet/roslyn#68785 (comment)

[Zetanova]

Yes, correct ?? [] implies that the array is a list of the left Type.
At the end we are searching for a sort form to skip/guard the foreach on null.
?? [] is only a fast-hack for it.

Current best:

if(msg.Items is not null) 
{
    foreach (var item in msg.Items)
    {
       // do somthing with item 
    }
}

[HaloFour]

@jnm2

Does there need to be an empty transient collection? Why couldn't the compiler recognize the pattern and optimize the expression away entirely? I'd handle it like tuples, where the compiler is free to make assumptions that said collection would have no side effects and can safely be elided entirely.

I wouldn't hobble the entire feature to handle a pathological edge case.

[jnm2]

I wouldn't use tuples as a point of comparison. The relevant bit of info which made that palatable is that tuples are implemented by a system type. If someone implements that type, they're taking on the burden of knowing they're in a special scenario that the compiler will play fast and loose with.

However, I would urge us to consider not requiring the empty transient collection. I'll comment in the roslyn implementation thread.

[jnm2]

A point of comparison could be the assumptions list patterns make on the well-behavedness of user-defined collection types.