Added: C# Design Notes for Jan 2018

[MadsTorgersen]

Many of these topics have evolved since these notes - the raw notes are available, but have yet to be cleaned up.

C# Language Design Notes for Jan 3, 2018

1. Scoping of expression variables in constructor initializer
2. Scoping of expression variables in field initializer
3. Scoping of expression variables in query clauses
4. Caller argument expression attribute
5. Other caller attributes
6. New constraints

C# Language Design Notes for Jan 10, 2018

1. Ranges and endpoint types

C# Language Design Notes for Jan 18, 2018

We discussed the range operator in C# and the underlying types for it.

1. Scope of the feature
2. Range types
3. Type name
4. Open-ended ranges
5. Empty ranges
6. Enumerability
7. Language questions

C# Language Design Notes for Jan 22, 2018

We continued to discuss the range operator in C# and the underlying types for it.

1. Inclusive or exclusive?
2. Natural type of range expressions
3. Start/length notation

C# Language Design Notes for Jan 24, 2018

1. Ref reassignment
2. New constraints
3. Target typed stackalloc initializers
4. Deconstruct as ref extension method

[bbarry]

Unblocking Array might be useful for some obscure scenario (like trigger the compiler to emit a for loop when you foreach over it?) but I cannot think of a reason why ValueType might be useful if we can use struct today and Enum in vNext.

Are there old notes around that explain why Array was given this treatment in the first place? If Range were to become a natural type, would those notes apply there?

[qrli]

For range: It reads like you think negative index will not be used for indexing. But it is common for 1..-2 to denote from index 1 to length - 2. e.g. in Python, or even in Powershell. So, such syntax will not be supported?

[orthoxerox]

Was there any specific reason why you didn't discuss supporting both right-inclusive and right-exclusive ranges?

[Logerfo]

Wouldn't unblocking ValueType constraint solve the "numeric" problem? Today, if you want to accept any numeric value (float, decimal, double, short, long, int, unsigned..), you have to either declare multiple overloads or use an evil constraint as the following:

where T : struct, IComparable, IFormattable, IConvertible, IComparable<T>, IEquatable<T>

Which accepts every numeric type, but still allows custom structs that implement all those interfaces.
I think there is an issue for that, but I cannot find it.

[bbarry]

@Logerfo No, ValueType is the base type for any struct or enum. Perhaps there could be other types that inherit from it but as a constraint ValueType would be more permitting than struct.

[ufcpp]

I prefer inclusive ranges for the range pattern, while I like exclusive ranges for the indexing purpose.

[Unknown6656]

NOOOOOOOOOOOOOOOOO!! - right-exclusive ranges are bad (IMO).
Yes, Yes - I know, they are easier to use, and more common and blah blah blah, but think about the following:

• What about keeping consistency with F#?
• What about keeping consistency with Mathematics!?
  In math, the expression [a, b] represents an incluse range,
  [a, b) a partially-exclusive one,
  and (a, b) an completely-exclusive one.
• (And think about consistency in its own syntax - why should [a be inclusive, but b] not?)

Think about those poor devs switching from/to F#. Do you really want to imitate Python instead of our brother F#?

And think about the mathematicians -- Our ancestors..... The ones, who laid the foundations of information technology and programming .....

Dear LDT, I think that right-exclusive ranges are a bad 'default' for ranges. Make them inclusive. Think about an other syntax for exclusiveness, e.g. [|a..b|], [a..b|] or something like that.

And most importantly - think about readability! For us mathematicians [a, b] means inclusiveness and making that exclusive is a huge wrong-decision for C#.

---

@MadsTorgersen @gafter

[alrz]

Think about those poor devs switching from/to F#

those that come from F# would be pretty damn shocked once they see the syntax for class.

[tannergooding]

I think both syntaxes have their drawbacks, and both should ultimately be provided. No one exclusively writes a < b (exclusive), just like no-one exclusively writes a <= b (inclusive). Instead, you use what is best suited to your needs.

Take some simple F# code:

module Test

let ForInclusive(length:int32) =
    for i = 0 to length do System.Console.WriteLine(i)
    
let ForExclusive(length:int32) =
    for i = 0 to (length - 1) do System.Console.WriteLine(i)

This gets compiled down to (essentially):

public static void ForInclusive(int length)
{
    int i = 0;
    int end = length;

    if (end >= i)
    {
        do
        {
            Console.WriteLine(i);
            i++;
        }
        while (i != (end + 1));
    }
}

public static void ForExclusive(int length)
{
    int i = 0;
    int end = (length - 1);

    if (end >= i)
    {
        do
        {
            Console.WriteLine(i);
            i++;
        }
        while (i != (end + 1));
    }
}

F# is doing all of this to protect against overflow bugs such as:

• length = 0
• (length - x) < 0
• end = int.MaxValue

[qrli]

To add some argument for exclusive:
Having worked with graphics, I'm very accustomed to exclusive ranges, because inclusive ranges give surprises surprisingly.

E.g. it is common to use the length of the range, and with exclusive range, that's End - Start regardless the type is int or float. If you want adjacent ranges, it is also simple a..b, b..c, again regardless of type. Inclusive ranges, on the other hand, easily get you into the off by one error.

It is counter intuitive at start, but when get used to, it feels like the one true ^(tm) way.

Exclusive is also the typical ways for indexing/slicing in C and derived languages, even in JavaScript. Some level of consistency is really beneficial as C# developers often also need to code some JavaScript, etc.

[Unknown6656]

JavaScript

Please do not use profanity in this repository ;)

[jnm2]

@Unknown6656 But what if I really like **********? 😓

[alrz]

We should allow expression variables in queries, but keep them scoped to the individual query clauses. In other words, they aren't range variables. They are normal variables scoped by the lambdas that we translate into.

Except that with query clauses, there is no syntactical lambdas, and therefore, one would expect scoping not be defined around those. I think one of the advantages of using linq is exactly that. The compiler should handle scoping etc of the variables introduced in a query clause and do not depend on the underlying lowered form.

[alrz]

With ref reassignment it now becomes meaningful to allow ref (and ref readonly) locals to be left uninitialized at declaration. In that case what should be their lifetime? We can discuss that later.

I think this can address #1130.

I propose we define retunability wrt the last value assigned (instead of the first value assigned)

var local = 42;
ref int r1;
r1 = ref local;
return ref r1; // ERROR
r1 = ref field;
return ref r1; // OK

Span<byte> s;
s = stackalloc byte[10];
return s; // ERROR
s = new byte[10];
return s; // OK

[gafter]

I propose we define retunability wrt the last value assigned (instead of the first value assigned)

When the code is not straight-line, which execution path should we use to decide which is "last"?

[CyrusNajmabadi]

I can't personally remember hte last time i used an inclusive range. On the other hand, i use exclusive ranges all the time (in C#, TS and Go).

Now, that said, it might be because so much of the compiler and IDE space fits exclusive-end-range math so well. We've already had Spans in that space with the VS.Span construct and the Roslyn.TextSpan construct. So maybe it's just utter familiarity there. However, it seems to just make the most sense with so much stuff i use spans for.

[alrz]

When the code is not straight-line, which execution path should we use to decide which is "last"?

Could be the most restrictive lifetime from all values that flows out of their individual blocks, making it identical to how we infer lifetimes from ternary operands.

Span<int> M1(bool b) {
  Span<int> s;
  if (b) s = new int[10];
  else s = stackalloc int[10]; // error here, with default lifetime (external)
  return s; // error here, with inferred lifetime (current)
}
    
Span<int> M2(bool b) {
  Span<int> s = b ? new int[10] : stackalloc int[10];
  return s; // error here, lifetime is inferred from intersection of both operands
}

[gafter]

I'm not sure this warrants a new data-flow pass in the compiler.

[CyrusNajmabadi]

What about keeping consistency with Mathematics!?
In math, the expression [a, b] represents an incluse range,
[a, b) a partially-exclusive one,

Note. The more i read this, the more i like it. [a, b] for right-inclusive, [a, b) for right-exclusive. Or [a..b] and [a..b). It's simple, consistent with mathematics, and supports the two more important scenarios out there. I don't think (a..b) is really necessary. While 'complete', it's a case i don't think i've ever head anyone asking for. Plut, it would be nice to not have to worry about the ambiguities there with parenthesized expressions and the like.

Having a delimited form also gives us flexibility for other things. For example, it gives us a simple place to put things like the stepping value (if we want to support that).

[JakubSarnik]

I too think that there should be syntax for both exclusive and inclusive ranges. There are no disadvantages to having 2 range operators instead of one and the feature will be more flexible that way. It is, of course, on the design committee to choose the correct syntax, but I think there is enough inspiration in languages such as Swift ('..<' for exclusive, '...' for inclusive; similar in Nim, but with one less dot).

Having inclusive ranges would also help programmers coming from F# and it would allow for specifying a range of enum values up to the end value without having to use any special syntax such as 'a..'.

[alrz]

FWIW, this is how Rust handle lifetime mismatch:

The lifetime region of a local is determined by usages of itself. not the value that is assigned to it (the exact opposite of status quo in C#), for instance,

// &param can escape
// &local can't

// 'ret' is not returned, so it has a local lifetime

fn f1(param: &i32) {
    let local = 5;
    let ret: &i32;
    let b = true;
    if b {
        ret = &local; // OK
    } else {
        ret = &param; // OK
    }
    let a = &ret;
}

// 'ret' is returned, so it has an external lifetime

fn f2(param: &i32) -> &i32 {
    let local = 5;
    let ret: &i32;
    let b = true;
    if b {
        ret = &local; // ERROR: local doesn't live long enough
    } else {
        ret = &param; // still OK
    }
    let a = &ret;
    return &a;
}