Records: lower empty records to a singleton

[alrz]

This was considered before but seems to be discarded silently.

A record is identified by a set of fields together with value semantics, meaning an empty record is practically a singleton and it could actually be implemented as such e.g. new EmptyRecord() would return the same instance everywhere.

[YairHalberstadt]

This will be useful if DUs are based on records as I think it would be expected that empty cases of a DU are singletons.

This should only apply to an empty positional record without any parameters or fields.

An alternative is something like Scala's case object which is a singleton as opposed to case class which is not..

[alrz]

I don't think DUs could be directly translated to records. Maybe if we have a mechabism to mark "closed class hierarchies", other than that there's no way to think of records as an expanded form of DUs.

Though I agree that equality impl, for instance, wouldn't be much different between the two.

[TheUnlocked]

Having Object.ReferenceEquals(new EmptyRecord(), new EmptyRecord()) be true could feel a bit strange. I don't know why someone would ever try to perform a reference equality check on two records, though it could come up in a generic function.

[alrz]

That's a good point. I believe this will be the way empty DUs will work, perhaps new could be omitted for those so there's no confusion on that front.

[AartBluestoke]

for readonly objects, anything which is valueEquals, could be referenceEquals or not, and that shouldn't make any difference. There's nothing stopping a serializer from caching the answer hand handing out the same readonly object multiple times (not that i believe that anything currently does that).

even strings with the same value might, or might not be ReferenceEquals, and that shouldn't be a surprise, or even matter.

[svick]

If this was implemented, what would happen if a record explicitly overrode equality to use reference equality?

record R
{
    public virtual bool Equals(R other) => ReferenceEquals(this, other);
    public override int GetHashCode() => RuntimeHelpers.GetHashCode(this);
}

[alrz]

That would be actually still correct. Because there's only one instance. In fact, you could just return true in this overload for the same reason.

However, anything else would be incorrect. I think there should be a less subtle way to define singletons. Notes do mention scala syntax. So perhaps we will see something in the future especially alongside DUs.

[theunrepentantgeek]

In a comment, on #490 I wrote

My concern with this idea is that most singleton's aren't.
It's common to need a singleton per request or a singleton per thread, not just a singleton per process.
Even for contexts where there would be exactly one instance in production, unit testing often requires a separate instance for each test, especially when using frameworks like xUnit that run tests in parallel.
I therefore suggest that singleton is more of a policy concern, not something that should be enforced by the language.

That was 4 years ago, but I still hold that those comments are true.

Further, if an empty record was silently lowered to a singleton by the compiler, it would be possible for someone to inadvertently write code dependent on that effect, making any change to the record that silently made it "not a singleton" a breaking change. Building landmines into the language doesn't seem like a good idea to me.

[HaloFour]

@theunrepentantgeek

These singletons only matter when there is nothing that can distinguish them from one another. Think of an empty struct. They would all have exactly the same value and be equivalent to each other. Records without fields are the same, they have the same value and value identity and should be considered equal across the language. As they can only have a single value the fact that you'd be sharing the same instance across multiple threads, requests or concurrent tests shouldn't matter in the slightest. Relying on reference equality in those cases would be the incorrect thing to do.

Another example would be Array.Empty<T>.