Added: Notes for September 28th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-09-28.md

Agenda

• Warning on double.NaN
• Triage

[huoyaoyuan]

We're currently tracking LINQ improvements, Task-like type covariance

I don't want to see more types recognized by compiler. Especially, for task, there are already many requests for covariancing Task<Derived> as Task<TBase>. Nullable covariance can be solved if that's a thing.

However, the somewhat-fractured nature of .NET here works to our detriment, not just in the Count vs Length property names, but in the general collection type sense.

Hopefully, we are going to add concepts/type classes, and this is a chance to add a new unified abstraction for collections.

[alrz]

I don't want to see more types recognized by compiler

There isn't something actively harmful about it but I can see your point.

I think it'll be complicated since only the "public" surface determines if either out or in is valid for a particular type parameter. Same is true for interfaces but interfaces already help to define that public surface in the first place.

[MgSam]

Not a fan of doing any work on anonymous types. They are practically obsolete since the introduction of tuples (ValueTuple) to the language. This seems entirely like wasted effort, IMO.

[HaloFour]

Anonymous types are used heavily as unnamed property bags in ASP.NET MVC and other similar frameworks. Tuples cannot replace them in those cases due to the inability to reflect over the names of their elements.

[MgSam]

Actually, I used to use anonymous types as view models in WPF (and expose them as object).

And this is a great reason why the team should not be improving anonymous types. They encourage bad practices like this one where people try to pass them around.

The need for a lightweight type with value equality that you can reflect over is about to be fulfilled- with records.

Between records + tuples, anonymous types should serve no useful purpose any longer. Further developing them only encourages bad practices. IMHO, they were always a half-baked, rushed idea anyway. The team openly admits they were only added to make LINQ work.

[HaloFour]

The need for a lightweight type with value equality that you can reflect over is about to be fulfilled- with records.

Except that requires yet another declaration and a lot of pointless repetition. Anonymous types weren't added because declaring such types is hard, it's because declaring such types is a waste of time. That's what the team openly admits to. They are the idiomatic approach for passing around unnamed projections and records do not change that anymore than tuples did (or struct records will).

[MgSam]

...it's because declaring such types is a waste of time...

If the 30 seconds it takes to declare such a type now that records exist is too much for you you're definitely using the wrong language. (And even that 30 seconds is decreased by using a decent tool like R# that can generate members for you as you reference them on an existing types.) Writing code is the least expensive part of the development process. Maintaining code, debugging code, optimizing code are exponentially more expensive.

Anonymous types make sense in JavaScript where declaring and using types has zero friction. In C#, anonymous types promote the use of a dangerous and completely unnecessary anti-pattern- returning them as object and then using dynamic to get at the contents. They also potentially generate tons of garbage in a way that is insidious and easy to miss for those less familiar with how the language works. A pit of failure rather than a pit of success.

They are the idiomatic approach for passing around unnamed projections and records do not change that anymore than tuples did (or struct records will).

I totally disagree. I haven't used anonymous types once since tuples were added. (Except out of muscle memory, which I then changed to a tuple when I caught myself.) One of the main design goals of tuples was to address the "passing around" shortcomings with anonymous types. Thus our ability to define them as "types" in method signatures rather than just having to use ValueTuple<Foo, Bar>.

Personally, I think anonymous types should be deprecated with a warning wave on the compiler alongside other obsolete features like anonymous delegate syntax. But the team is extremely squeamish about deprecating anything so that's unlikely to happen. But they certainly shouldn't waste finite dev resources augmenting it when there's hundreds of other more useful features on the backlog.

[HaloFour]

If the 30 seconds it takes to declare such a type now that records exist is too much for you you're definitely using the wrong language.

The time isn't relevant, it's a pointless declaration, and a LINQ query with a couple of projections could easily require many additional types that will not be reused elsewhere in code.

I totally disagree. I haven't used anonymous types once since tuples were added.

Personally, I think anonymous types should be deprecated with a warning wave on the compiler alongside other obsolete features like anonymous delegate syntax.

You're welcome to your opinion, and you can feel free to avoid any language feature that you personally disagree with, however that doesn't make said feature either obsolete or deprecated.

[alrz]

Proposal: Add ability to declare global usings for namespaces, types and aliases by using a command line switch

Still in favor of global usings for a number of reasons (#3428 (comment)). I worry that with the presence of cli option, actually introducing globals on top of that will divide the community (via multiple ways of doing the same thing)

Proposal: Extend with expression to anonymous type

There are codebases which already use anonymous types extensively. In those cases, the anonymous type won't live long enough - before converting to object - to even have a chance to consider using with if at all helpful. Regardless, this will increase the size of all those binaries with a non-trivial amount of unused code (the generated Clone method)

we hit upon the idea of additionally allowing new { } to be target-typed.

I wasn't quite convinced that this is doable without a complex set of rules. This was explicitly put aside to avoid just that.

Proposal: List Patterns

On IEnumerable support. I think a wrapper type which would lazily enumerate on indexer access and cache the result will do the job. I don't think the compiler could do any better with direct support. (edit: Scratch that. We need to check Count as the first step so lazy enumeration is not possible)

On dictionary support. I still think user-defined positional patterns is the way to go, but it's an additional feature so I don't have a strong opinion on that.

Quite interested to hear the ideas around using braces without breaking empty property pattern.

Champion: Simplified parameter null validation code

Hopeful to see this as an attribute. It's a simple feature that would enable lots of scenarios before we get to method contracts.

[HaloFour]

@333fred

I don't get how that would work short of also allowing anonymous types to also implement interfaces or extend from base classes. A "wither" constraint seems pointless if you can clone but don't know what properties you can then initialize in that method. Unless you're picturing "wither" factories that return an instance that's still being "initialized"?

[333fred]

A "wither" constraint seems pointless if you can clone but don't know what properties you can then initialize in that method.

I was picturing how they would work with shapes/roles if we end up going a fully structural route there.

[alrz]

Is it just for consistency or do we have an actual use case?

A "wither" constraint seems pointless if you can clone but don't know what properties you can then initialize in that method

I think this is the core issue here. Earlier I said "the anonymous type won't live long enough - before converting to object - to even have a chance to consider using with if at all helpful.". My question being: Does anyone actually use anonymous types like this? e.g. holding on to it (to preserve the type) and maybe assigning it using with to some other variable?

[alrz]

I was picturing how they would work with shapes/roles if we end up going a fully structural route there.

Guess there's my answer. So anonymous type with support wouldn't be much useful without shapes

[333fred]

So anonymous type with support wouldn't be much useful without shapes

It wouldn't be useful in external APIs without shapes. It could certainly be useful internal to a method, and given the extremely small cost of implementing the feature, I think it's worth doing.