Added: LDM notes for June 1, 2020

[agocke]

C# Language Design Notes for June 1, 2020

Records:
1. Base call syntax
2. Synthesizing positional record members and assignments
3. Record equality through inheritance

[qrli]

Maybe I should ask in this thread:

A: For the first record in a type hierarchy, we should define equality based on all the accessible fields, including inherited ones, in the record.

Does it mean that a record may derive from a non-record class?

• If yes, does it mean, at the concept level (other than implementation), a record is a class?
• What if the base class does not obey record rules?
• What if a new version of the base class, e.g. in 3rd party library, break some record rules? (E.g. its author may not have foreseen it to be inherited by a record.)

[HaloFour]

@agocke

I don't like the idea of not taking into consideration the equality of the base type if that base type is not a record. I think it will lead to unexpected consequences:

// defined in some assembly somewhere:
public abstract class Entity {
    public int ID { get; }
    protected Entity(int id) { ... }
    // has members Equals/GetHashCode based on the value of ID
}

// defined in my assembly:
public record Person(int ID, string First, string Last) : Entity(ID);

var person1 = new Person(100, "John", "Smith");
var person2 = new Person(101, "John", "Smith");

if (person1.Equals(person2)) {
    Console.WriteLine("Oops, this is broken!");
}

I reiterate that I think that the C# compiler should always call base.Equals and base.GetHashCode when they are overridden by any class in the hierarchy and only elide that call if the most specific override is to the instance member of System.Object. This is how it works in Scala and it is what I think developers would naturally intuit about records.

[bbarry]

I don't like the idea that records can have a base type that is not a record (or a single specific BCL root type for all records that goes unspecified by default and is an error to explicitly write).

[omariom]

@agocke
Btw, why the generated Equals uses EqualityComparer for primitives types?
Wouldn't it be simpler, less IL, and potentially more efficient to use native comparisons for the types Roslyn knows about?

[CyrusNajmabadi]

Btw, why the generated Equals uses EqualityComparer for primitives types?

THe lang spec defines things in terms of simple semantics. The implementation is free to optimize as long as those semantics are preserved.

[omariom]

The implementation is free to optimize

What can be more optimized than direct comparison on the IL level? 🤔

Note how for strings the call to GenericEqualityComparer is not inlined.

The implementation is getting more and more complex in the business of generatin code. It has now tiered compilation, intepreter, ready2run, corert, mono translates to LLVM bitcode etc.

[CyrusNajmabadi]

What can be more optimized than direct comparison on the IL level?

yes. that's what i'm saying. the implementation is free to emit that. there's no need for the language to state that that's what will happen.

[CyrusNajmabadi]

Note how for strings the call to GenericEqualityComparer is not inlined.

I don't see how that's relevant. As i mentioned, the implemntation is free to inline this itself. It's out of the purview of the language.

It has now tiered compilation, intepreter, ready2run, corert, mono translates to LLVM bitcode etc.

It sounds lke you're discussing the runtime. I'm talking about the compiler.

[omariom]

As i mentioned, the implemntation is free to inline this itself

The language could do the implementation a favour.

I'm talking about the compiler.

It is not clear why the compiler chose to use EqualityComparer in non-generic context (for which EqualityComparer was created).
Why it uses ceq in some cases and EqualityComparer in others?

[CyrusNajmabadi]

It is not clear why the compiler chose to use EqualityComparer in non-generic context (for which EqualityComparer was created).

Can you give an example of that?

Why it uses ceq in some cases and EqualityComparer in others?

If you would ike the compiler to more efficiently implement some language operations, you can file issues over at dotnet/roslyn.

[agocke]

Cyrus is right that I don't think we need to specify this in the language, and as to why we use EqualityComparer -- honestly I don't know. 😄 I reused the implementation for anonymous types, which use EqualityComparer. I don't see any reason why we couldn't change it, as long as the appropriate semantics are preserved.