LDM Notes for April 3rd, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-04-03.md

Agenda

• Collection Literals
• Fixed-size buffers

[huoyaoyuan]

Some words for collections:

There should be more contract fulfilled with code about known members (Length or Count), rather than duck typing only. This applies to even more concepts like GetAwaiter. A realistic benefit is that if the contract is explicitly adopted by library creator, there can be analyzers to warn for violations (side effect in Count etc.).

Such contracts may not be expressible in C# type system now (Interface vs HKT Concepts, pure methods), but we should keep these in mind and find ways to express them in the future.

[CyrusNajmabadi]

can you give an example of a collection today that has observable side effects in Length/Count?

[huoyaoyuan]

I don't know any in open source space. Collection is just an example. What I want is an intentional mark about "satisfying certain language feature". This topic might be out of scope here.

[CyrusNajmabadi]

What I want is an intentional mark about "satisfying certain language feature"

Absent any motivating examples, that just seems like extra work that doesn't end up providing much value. For example, we don't do anything like that for patterns (and those assume well behaved code as well). It doesn't appear to have been a problem there either. So this doesn't seem like something (currently) worthwhile to put extra effort into. :)

[TonyValenti]

Similar to how async/await rely on Task(like)s, I feel like collection literals should be backed by some new CLR "collection builder" type that works in tandem with the compiler.

Today, I already do some thing similar to this by using List and an Add extension method that accepts enumerables. I don't gain all the benefits that the compiler could leverage, but it is quite handy!

[333fred]

You might want to check out the broader proposal details in the spec 😉.