New conditional operator: !:

[Rekkonnect]

I've been told from a friend of mine that in Python there is a conditional operator like the following one:

i = 2
eg = ['a', 'b', 'c', 'd', 'e'][i]
! eg will be 'c' in that example

In C# there is nothing like it, so I thought that it should be added in some way. Following the philosophy of the language, I came up with the idea of this new operator that goes like this:

int a = 2;
string b = a ! { "a", "b", "c", "d", "e" } : "default";
// b will be "c" since this value is on the specified index in the array

int a = 6;
string b = a ! { "a", "b", "c", "d", "e" } : "default";
// b will be "default" because the index that was specified is out of bounds of the array

As for that operator, I think it's a useful addition because of the existence of the ?: conditional operator, which only applies for booleans.

[jnm2]

In C# there is something like it, but it doesn't handle the default case:

var i = 2;
var eg = new[] { 'a', 'b', 'c', 'd', 'e' }[i];
// eg will be 'c' in that example

Easy enough to write a helper method for it though:

var a = 2;
var b = Choose(a, new[] { "a", "b", "c", "d", "e" }, "default");
// b will be "c" since this value is on the specified index in the array

public static T Choose<T>(int index, T[] options, T @default)
{
    if (options == null) throw new ArgumentNullException(nameof(options));
    return index >= 0 && index < options.Length ? options[index] : @default;
}

[Rekkonnect]

Yeah okay, that's what I have sorta implemented in some case where I needed this, but why not just add this operator for simplicity? If you say no because something else like that also exists, then consider the ?: operator which is an alternative for something even simpler.

[HaloFour]

Requiring an array allocation to perform such an operation would make this pretty awful from a performance point of view.

[jnm2]

@alfasgd

If you say no because something else like that also exists

I didn't say no, just adding to the discussion. However if I did say no it would be for a different reason. I am not convinced that this is a common enough scenario that using the helper method or a switch wouldn't be better for the rare cases when you need it.

[Rekkonnect]

It really is useful in such cases, even if they are rare enough. At least in my point of view, I do not see any reason why not to simply add such an operator.

[HaloFour]

The question is "why", not "why not". Every language feature has to be justifiable. This is a relatively rare operation that is already very easily solved today with a helper function or extension method. And even if such syntax is idiomatic in Python it would perform quite poorly in C# and thus shouldn't be encouraged.

[jnm2]

@alfasgd Because it adds complexity and could block future scenarios we didn't think of yet that could have much more value. Every new feature starts at -1000 points at this point.

[jnm2]

Requiring an array allocation to perform such an operation would make this pretty awful from a performance point of view.

This is what I was going to suggest next for both perf and syntax, as it turns out:

var y = Choose(x, ("a", "b"), "default");

public static T Choose<T>(int index, (T, T) options, T @default)
{
    switch (index)
    {
        case 0:
            return options.Item1;
        case 1:
            return options.Item2;
        // etc
        default:
            return @default;
    }
}

[HaloFour]

@jnm2

Good call. You'd need an method per arity but you'd only have to write that once. It's even nicer as an extension method:

var y = ("a, "b").Choose(x, "default");

Extension operators could make that terser, whether that's a good thing or not:

var y = ("a", "b")[x, "default"];

[jnm2]

@HaloFour I'd expect ("a", "b")[x] to throw for index out of range, but if ("a", "b")[x, "default"] was available the convention would be for ("a", "b")[x] to mean ("a", "b")[x, default(T)]. Therefore I'd rather eschew ("a", "b")[x, "default"] for ("a", "b").Choose(x, "default") or GetValueOrDefault.

[bondsbw]

This works today:

int a = 2;
string b = new[] { "a", "b", "c", "d", "e" }.ElementAtOrDefault(a) ?? "default";

As a language construct, I would suggest a conditional indexer to look more like

collection[?index]

This would return the item if the index is valid, or default(T) otherwise. It could be combined with ?? to achieve the requested effect:

int a = 2;
string b = new[] { "a", "b", "c", "d", "e" }[?a] ?? "default";

[jnm2]

@bondsbw What about value types?

[bondsbw]

@jnm2 In that case the problem isn't so much any of the new syntax, but ??.

Maybe as a separate proposal, ?? could be changed into a default-coalescing operator, instead of just null-coalescing. Then it would work.

[jnm2]

@bondsbw Actually, default-coalescing would not work here:

var a = 2;
var b = new[] { 2, 1, 0 }[?a] ?defaultcoalesce? -1;

b should be 0, but the default coalesce turns it into -1.

We need to be able to differentiate between returning an in-range value which happens to be default(T) and being out of range.

[bondsbw]

True, and there was a proposal (#328) for transforming ?? into default-coalescing that was shot down for good reasons.

Other ideas for syntax I considered posting earlier were:

collection[?index : defaultValue]

collection[index ?: defaultValue]

I wasn't in love with these. But, they aren't quite as foreign either. (One upside is that they would work better with chaining.)

[bondsbw]

Also with that syntax we could still have

collection[?index]

as a shorthand for

collection[?index : default(T)]

for situations where the default is the preferred output when the index doesn't exist.

[HaloFour]

@bondsbw

I'd put such an operator into the same category as dotnet/roslyn#5961, in that an expression applied to a parameter to another expression, whether that be a method call or an indexer operator, should not affect the execution of that method/operator.

For as infrequently as such an operation is needed, and the fact that the functionality is already provided by LINQ, I don't see a reason for a language construct.

[bondsbw]

@HaloFour The ? is not applied to the expression index as in dotnet/roslyn#5961, but rather it is part of a new operator [? : ]. It doesn't default based on evaluating index itself, but based on the validity of applying index as a key. In other words, collection[?(index)] is correct, and collection[(?index)] is not.

Though I agree about finding little value in it regardless of the syntax chosen. Readability suffers compared with existing mechanisms.

[svick]

@bondsbw I think it would be confusing if both collection?[index] and collection[?index] (and presumably also collection?[?index]) were valid. And the former is already valid syntax.

[ufcpp]

> new[] { "a", "b", "c", "d", "e" }.ElementAtOrDefault(2) ?? "default"
"c"
> new[] { "a", "b", "c", "d", "e" }.ElementAtOrDefault(6) ?? "default"
"default"

[qaqz111]

There's no need to add a new operator to do this, it just increases the complexity and learning cost of language.

What you need is simply an extension method:

public static TSource ElemAtOrValue<TSource>(this IEnumerable<TSource> source, int index, TSource val)
{
    if (null != source && 0 <= index)
    {
        if (source is IReadOnlyList<TSource> rlist)
        {
            if (rlist.Count > index) return rlist[index];
        }
        else
        {
            foreach (var src in source)
            {
                if (0 == index) return src;
                --index;
            }
        }
    }

    return val;
}

[jnm2]

@ufcpp As mentioned above, ElementAtOrDefault does not work when selecting from value types where you want to choose a different value for the default case than the literal default value of the value type (zeros).

(E.g. new[] { 1, 2, 3 }.ElementAtOrDefault(6) ?? 10)