Collection expressions: synthesize single-element list type for IEnumerable<T>, IReadOnlyCollection<T>, IReadOnlyList<T>

[alrz]

Contributes to #68785

[alrz]

@cston I'd like a review pass on this before I add tests and check well-known members. The enumerator should probably be a nested type.. is there a sample I can follow to make it so? or it's ok for it to be top-level?

[CyrusNajmabadi]

Awesome!!

[CyrusNajmabadi]

@alrz will this cause conflicts with the work @jnm2 is doing in: #71110 ?

Just want to make sure you both are not colliding at the same time.

[cston]

Thanks @alrz, the changes so far LGTM!

The enumerator should probably be a nested type.. is there a sample I can follow to make it so? or it's ok for it to be top-level?

I agree, the enumerator type should probably be a nested type. I don't know if we have an example of a nested synthesized type, but perhaps the following changes are needed:

• Use the list type as the enumerator type ContainingSymbol
• Include the enumerator type in the list type GetTypeMembers()
• Adjust enumerator type Arity and TypeParameters since the containing type is generic
• Update PrivateImplementationDetails.GetTopLevelTypeMethods() to return the methods from type.GetNestedTypes(context) for each top-level type

[alrz]

@CyrusNajmabadi

will this cause conflicts with the work @jnm2 is doing in: #71110 ?

thanks for the heads up. I haven't started checking well-known members yet so it won't. I will sync once that PR goes in.

btw, would this interact with the planned yield-like codegen (from #68785)?

also I was wondering what would it take to remove SpecializedCollections; maybe synthesize empty types as well?

[CyrusNajmabadi]

btw, would this interact with the planned yield-like codegen

Most likely yes :)

also I was wondering what would it take to remove SpecializedCollections; maybe synthesize empty types as well?

I would be fine with synthesizing empty singleton types. :)

But, frankly, we likely should just use the known Array.Empty singleton for these instead.

[alrz]

But, frankly, we likely should just use the known Array.Empty singleton for these instead.

I'm assuming there's a reason that both roslyn/runtime have a special type for this. Maybe saving a tiny bit of memory?
There's actually Enumerable.Empty<T>() for enumerables but not for ReadonlyList or ReadonlyCollection.

[CyrusNajmabadi]

I'm assuming there's a reason that both roslyn/runtime have a special type for this.

Having one actual object exist and be pointed to by literally millions of locations in memory is good :)

[alrz]

@cston @dotnet/roslyn-compiler for review, thanks.

[cston]

@dotnet/roslyn-compiler for a second review, thanks.

[cston]

@dotnet/roslyn-compiler for a second review, thanks.

[cston]

@333fred, @RikkiGibson, @dotnet/roslyn-compiler, for a second review, thanks.

[333fred]

Done review pass

[333fred]

I know you didn't name this variable, but... number of what? We need to rename this for clarity. If you want to do it now, go for it, if not we can do it in a follow up.

[alrz]

Tried lastSpreadIndex here 57dc299 but that's more than a rename. I'll leave it out of this PR.

[alrz]

CanCreateSingleElement

This runs for every single-element collection expr unlike SynthesizedReadOnlyListTypeSymbol.Create. Not sure if this matters but I think we can detect this in EnsureReadOnlyListTypeExists and downgrade instead of checking each time, although that would only optimize the happy path.

[cston]

Thanks @alrz!