[Proposal] SQL syntax "in" "not in" for checks

[juniorgasparotto]

Hi,

I think the linq idea brought some of the SQL standard into C #. However, I believe there is room for other features like "in, not in" to be added in the language. I can not imagine how difficult this is, but it's just an idea.

FROM:

var variable = 10;
if (variable == 0 || variable == 10) {
// Code
}

var variable = new List<string>() {
"value",
"Value2"
};

if (variable.Contains("value")) {
// Code
}

TO

   var variable = 10;
if (variable in (0, 5)) {
// Code
}

var variable = 10;
if (variable not in (0, 5)) {
// Code
}

var variable = new List<string>() {
"value",
"Value2"
};

if (variable in ("value")) {
// Code
}

The "in" command would be an alias of the "==" operator and would be reflected in case of overloading that operator.

Thanks

[yaakov-h]

I think a in b is supposed to be coming with ranges, but I can't find a championed proposal issue to link here. 😕

[james-uffindell-granta]

There's some discussion on #198 about this, but not much on #185.

Would it not be better for 'in' to call the .Equals method, instead of the == operator? Or, similar to is patterns, to call == on integral types and .Equals on other types?

[DavidArno]

@yaakov-h, I think it's effectively covered by #185.

The biggest problem I see though with having ranges for loops and patterns (as per this request) is that exclusive ranges make sense for loops, but inclusive ranges make sense for patterns:

foreach (var i in 0 .. collection.Count) ... // i should be from 0 to collection.Count - 1

if (collection.Count is in 1 .. 5) ... // collection.Count == 5 should match

[svick]

I find it very confusing that the proposed in seems to be symmetric, i.e. that you can use it as "value in collection" or "collection in value". Code like the following doesn't make sense to me:

if (new List<string> { "value", "value2" } in ("value")) {
    // Code
}

[DavidArno]

@svick, I'm with you there. I've no idea what that code is supposed to do or why it would be valid.

[juniorgasparotto]

I agree, this syntax is very strange for lists.

But I think for "simple variables" this syntax would be very useful. This eliminates IFs with many ORs for the same variable.

However, I appreciate everyone's response and I understand that this type of implementation is not simple.

[ricardogaldino]

Hi,

I believe that the syntax "in" makes more sense and is more intuitive, because the idea is: return a list of items where the field is contained between values or select from a list its items where the field is contained between the values.

I think the same way about the List Field or Table Field...

"Items of List "in" Values"

Example:

var names = new List() { "Ricardo", "Glauber", "xpto" };

I prefer this syntax:

var clients = from c in clients
where c.name in names
select c

than that:

var clients = from c in clients
where names.Contains(c.name)
select c

......

In the case of "if" the syntax would have something like:

if(clients.Any(c=> c.name in names))
{
...
}

[sirgru]

Similar request:
#420

People can recommend this or that alternative with LINQ and IE, but those have a significant performance impact for just a bit of syntactic sugar, which makes it 100% worthless for me.

For example, knowing C# this code: if (collection.Count is in 1 .. 5) will allocate an array to fill the whole range, then iterate over all elements in range checking them one by one. I hope I'm wrong but this would totally suck. What we really want is checking the bounds OR a finite set of values.

[asyncawaitmvvm]

I'm with you there. I've no idea what that code is supposed to do or why it would be valid.

Because it's irrelevant and meant to obfuscate the topic. Just like what you keep saying about "this is covered by _" even though it isn't. An In(params) extension method allocates an array, which is what you do not want. "in" needs to be a first class operator just like it is in Pascal/Delphi.

[juniorgasparotto]

For lists it may not be simple and performative, but for simple variables. I think it's an interesting idea.

Is there any planning for something like this to exist in language?

FROM:

var variable = 10;
if (variable == 0 ||  variable == 5 || variable == 1) {
// Code
}

var variable = 10;
if (variable != 0 ||  variable != 5 || variable != 1) {
// Code
}

TO:

var variable = 10;
if (variable in (0, 5, 1)) {
// Code
}

var variable = 10;
if (variable not in (0, 5, 1)) {
// Code
}

Thank you

[Kryptos-FR]

So that would be similar to just doing

var variable  = 10;
if ((new[]{0, 5, 1}).Contains(variable))
{
    //
}

Or with an extension method:

public static bool In<T>(this T value, params T[] args)
{
    return args.Contains(value):
}

var variable  = 10;
if (10.In(0, 5, 1))
{
    //
}

I don't think the cost of adding such feature is worth the relatively limited usage it can have.
If it is for performance reason, I think it is better to first support Span<T> for params as in #535. Then support slicing range as in #185. At that point, I believe that feature would not be needed anymore.

[juniorgasparotto]

I agree that there are other ways of doing what I am proposing (Extension Methods .. ). But I still think this syntax (inherited from SQL) is very didactic, intuitive and atractive for programmers.

In addition, there are other features that have been added in the C # language and that were not needed either, for example: "local functions".

Before the "local functions", it was possible to obtain the same result only with "delegate" or "Action / Func", but they are more beautiful and didactic, as well as my proposal.

Anyway thank you for the attention and opinion of all.

[james-uffindell-granta]

I've definitely wanted to write if (value in (3, 5)) or similar a lot of times, and it's always been a little irritating to me that I have to write if (new[]{3, 5}.Contains(value)) instead (yes, or make an extension method).

Could the 'in' pattern be just something you get automatically by implementing a Contains method, similarly to the existing LINQ query methods and query syntax?

So, if you want to be able to do

T x;
C<T> coll;
...
if (x is in coll) {

then you just need an instance or extension method on the collection type

public bool Contains(this C<T> coll, T x)

and x is in coll could be translated to coll.Contains(x).

Most collections already have this method; you wouldn't need to add a new In() extension method; range types could easily provide a bounds-checking implementation for efficiency; and you could also create a tuple extension method for small cases too if you want to use tuples:

public bool Contains (this (T a, T b, T c) tuple, T value)
    => value == a || value == b || value == c;

// then you could do
if (val is in (3, 5, 7)) {

[MgSam]

Please uncapitalize those Ifs in your proposal! :)

[whoisj]

new[]{3, 5}.Contains(value)

Ug, that allocates every evaluation 😞🐼 - just mentioning it because you really ought not be doing this when possible (except in test code, nobody seems to care about test code).

[james-uffindell-birt]

@whoisj sure, in a hot path all the allocations could add up, and in real code you would probably also argue that 3 and 5 are magic numbers and you should instead go for something like

var fizzBuzzNumbers = new ReadOnlyList<int> { 3, 5 };
...
if (fizzBuzzNumbers.Contains(value)) {

which isn't that ugly to read.

Or that, if you've only got two values to check, if (value == 3 || value == 5) is pretty much fine. Or that, if we get 'or'-patterns, then a constant case like this could be written as if (value is 3 or 5), which is also pretty much fine. I'm not sure I could come up with an example of "real code" where the value of being able to write it as an 'in'-pattern is actually clear-cut.

And yet, every time I write an if statement like this, I always phrase it in my mind as "if the value is in the collection", rather than "if the collection contains the value": the value is the 'active object', as it were, in the code I'm writing, so it feels like it should be the subject of the code 'sentence', and it's always slightly irritating that I can't write it that way.

And, if we are getting ranges and range patterns, we'd be able to use 'in' like this in some places - with range literals in case statements and if statements - and it would seem more irritating to me to be able to say it the 'nice way' for range literals, and have to still resort to the not-nice way for non-contiguous small sets:

if (value is in 3..8) { // fine, compiles to a simple bounds check
...
var allowedNumbers = new[] { 3, 5, 7};
if (allowedNumbers.Contains(value)) { // urgh

If we don't get range patterns then it's less irksome because the only way to do it is with a Contains() call, so at least it's the same everywhere.

But if we do have range patterns, since a range is a type of collection, you would be able to call Contains() on a range:

if ((3..8).Contains(value)) {

and this should always, surely, be equivalent to the corresponding 'in'-pattern. So, if 'in'-patterns work on ranges, and are equivalent to Contains() on ranges, it seems reasonable to support 'in'-patterns on any other type with a Contains() method, and this idea also seems to mesh well with the other keywords-to-methods translation done in LINQ. So, even in the absence of a massively compelling code example, it still feels like this feature should exist if ranges and range patterns come in.

[HaloFour]

@juniorgasparotto

Is there any planning for something like this to exist in language?

Potentially with pattern matching: #1350

if (variable is 0 or 5 or 1) { ... }

[scalablecory]

I would really like this syntax, especially if we can have some guarantees around implementation efficiency (i.e. if all the items are constant, it should transform down to a switch)

[The-Futurist]

@dsyme @DavidArno

Every release seems to be borrowing something from F# and I wonder now if this is indirectly hurting the adoption of F#. If C# continues to offer functional-like capabilities like this what would ever compel an organization to seriously try to leverage F#?

Advocate: "F# has this great way of doing..."

C# Developer: "Ahh but in C# 9.7 they're adding support for..."

Advocate: "OK, but also look at F#'s record concept that's cool..."

C# Developer: "Ahh but in C# 9.8 they're adding support for..."

etc etc.

F# is already a hybrid functional-OO language with emphasis on functional, but now C# is becoming an OO-functional language with emphasis on OO but sooner or later the choice will become more and more clouded and reduce the motivation for adopting F# especially when there are so many C# developers around already.

Making a case for F# in an organization that already has C# developers is thus made harder each year because F# advocates must present sound cases for such a move and often to those who are skeptical, the smaller the "gap" between the two languages the harder it is to make a case, Microsoft might want to at least consider this as they mutate C# more and more.

[DavidArno]

@Korporal, yes. And? Keep up the good work, I say.

Millions of folk use C#. 10,000's use F#. So why should those millions move to F# when F#'s features can be added to the language they are already using?

[The-Futurist]

@DavidArno - Exactly, why should Microsoft and the F# team continue to invest in and promote F# if C# is morphing into it. My opinion is that this ongoing "functionalization" of C# undermines the entire F# initiative. I'm also beginning to think that the C# changes were seeing are beginning to really make the language into a bizarre mutation.

Will we soon see the emergence of computation expressions for C#?

[scalablecory]

@Korporal C# should not be held back to assist any other language's popularity. That is ridiculous.

[The-Futurist]

@scalablecory - You may be correct, it's a matter of opinion though. As for "held back" I never once suggested that language should be held back only that the increasing emphasis on adding F#-like capabilities be stopped because C# is an OO language.

There are two reasons why I say this:

1. It undermines the investment that Microsoft and the community are making in F#.
2. It's creating a mutant language that will become overly complex and idiosyncratic.

Some of the fuss being made over quite esoteric new features for C# while at the same time refusing to seriously consider support for something as simple and obvious as continue label and break label for loops demonstrates what I'm saying I think.

[scalablecory]

@Korporal the days of languages being purely OO or purely functional are over. There is no benefit to drawing a line in the sand - so long as a feature can be implemented in a way that is idiomatic to the language and provides broad benefit, it is fair game for consideration.

And again, undermining another language is a terrible reason to hold back C#. You will get more support by arguing for or against the feature's merit.

[The-Futurist]

@scalablecory - you wrote:

And again, undermining another language is a terrible reason to hold back C#.

Which may be fine for some people, but it does amount - in this case - to C# competing with F# and hardly inspires growing confidence in the entire F# program Microsoft have invested in and encouraged customers to invest in.

F# is far beyond C# in many way but if C# continues to morph and chip away at F# then the relative strength of the language will diminish and eventually F# will just be another interesting curiosity in the history of programming languages.

[dsyme]

I don't really know why F# is being mentioned on this thread which turned up in my inbox. But I think it's entirely pointless to have an argument predicated on the idea that C# is "becoming" F#, because it just isn't.

I'm not arguing one is better than the other, though as the designer of F# I of course love F#. But I've written some C# recently and it's very clear to me that C# is not "morphing into" F#.

That's not to say C# is not improving - it is and that is great. But to be honest the differences are huge. Some quick examples:

• significant-but-important differences in specific features which have some resemblance (sequence expressions, object expressions, list/array comprehensions, tuples, computation expressions, pattern matching, task/async, type inference just to name a few sources of major difference - not all necessarily in favour of F#, I'm just listing them)
• specific large features (e.g. primary constructors and closure on object types, removed from C# 6)
• how the features are tuned, especially w.r.t. mutability
• orthogonality of features (let, let, let in F#)
• methodological assumptions (functional-first v. object-oriented)
• whether features are normative (let's be honest, using tuples in C# is not normative and unlikely to be so for a very very long time)
• null (let's be honest, it will 10x years to remove that from the overall C# ecosystem, if ever...)

There are others, and I've listed those features from an F# perspective, but a list can perhaps be made the other way around too.

When I see even "functional" C# code, it sure ain't F#, though there's plenty of goodness to it. But I agree with the above points that it would be entirely wrong to "hold back" C#, which can and should continue to improve along its natural path. But if you want the cost/benefits of programming in F# (hint: some costs, often lots of benefits), don't wait for C# to become F#, since it will never happen.

[Joe4evr]

primary constructors [...] removed from C# 6 and I think unlikely to ever make it in

So I guess you didn't hear about Primary Constructors being further developed into Record Types?

[R2D221]

I support transforming in to .Contains() mimicking other LINQ keywords. This would also solve the problem with ranges because

if (number is in (3..8))

would be translated to

if ((3..8).Contains(number))

and the Contains method in the Range would then do a bounds check (not iterate every number)

public bool Contains(int number)
{
    return number >= min && number <= max; // or however the bounds are defined in Range
}

And overall this would make LINQ closer to SQL, where we already use in and it's kind of confusing to declare an array and call Contains in the opposite order just to achieve the same (which fortunately is correctly translated to in, at least in Entity Framework and SQL Server).