LDM Notes for February 26th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-02-26.md

Agenda

• ref structs in generics
• Collection expressions

[TahirAhmadov]

For the WinForms etc collections, I vote option 2 - very strange to modify the language because of a few very old types, which need to be updated anyway.

[CyrusNajmabadi]

Taht's probably true. The point as looking at how several collection-esque types allow .Add(string) (which would be fine for a collection-initializer space). We can pick some other type if that makes people more comfortable. But it doesn't change the argument at all, since we're not saying we want this specific type to work, just types like it that would otherwise have worked when we shipped C#12 but now are broken. That means supporting types that allowed for different overloads of 'Add' just as collection-initializers always allowed.

[TahirAhmadov]

It's not as much about being "comfortable", rather about being able to look at specific options and whether they help this or that type. I almost think the maintainers of WinForms, WPF, etc. should pitch in and tell us which types they think should be supported and how. What if all these "collection-esque" types turn out to be not really good candidates for C.E.s at all once you look at each one of them? Then it would be a shame that all this time was wasted discussing a non-problem.

Regarding interfaces, for what it's worth, some types got IEnumerable<T> implementation, like MatchCollection, and that didn't warrant this level of alarm about potential breaks. Again, input from library maintainers would be very helpful here.

[CyrusNajmabadi]

Put another way, we've never dissuaded anyone from this aspect of the language in all the time since we shipped this support. Collection-initializers intentionally supported this pattern precisely because it was fine. And we shipped C#12 respecting that. The issue is dealing with a post-ship change that broke this support.

[TahirAhmadov]

I'd like to underscore the importance of concrete examples. In this case, a language decision was made, which potentially precludes some collection types from participating in a certain way. The way I see it, it's possible that either 1) the language change was in error and that these collections need to be supported, or 2) the language change was correct and these types are not really collections, and the fact that they are not supported being unexpected does not make it a change in the wrong direction. Sometimes unexpected changes are good.

[CyrusNajmabadi]

the language change was correct and these types are not really collections,

The types are collections. We made that very clear in the design of collection-initializers.

Sometimes unexpected changes are good.

These changes have already broken customers. Customers who have collection types that work completely fine with collection-initializers, using the exact pattern we have documented and espoused since C#3.0 (nearly 17 years old). In all that time we have never once said the pattern is wrong or undesirable. Furthermore, when creating, documenting and discussing collection expressions with those same customers, we stated explicitly that it was intentional and a goal of the feature that those cases would move forward.

It is expected that users who use collection-initializers be able to move them forward. The only cases not supported are those we deliberately looked at and said we didnt' have an actual solution for (for example, providing a collection argument, or being multi-dimensional). However, outside of the carved out cases (which are thinsg we do want to look into supporting for the future mind you, so that everyone can move forward), accidental blockages especially on shipped support is not desirable.

[iam3yal]

Just wondering whether the keyword let was discussed? as opposed to allow or even allows.

[colejohnson66]

I don't like that. let is commonly associated with binding (JS, Rust, F#, etc.), not constraints. Using it in a generic constraint would read weird: where T : let ref struct.

[jnm2]

let T : ref struct sounds a bit less awkward, but the decision was already made that having to look in two different clauses to understand T was not preferable.

[iam3yal]

@colejohnson66 I don't disagree but yes my thoughts were more aligned with the way @jnm2 expressed it.

Not that it matters but personally I dislike allows and allow even more but I'm not opposed to it, I trust the LDT to make the right decision. :)

[333fred]

We did not discuss let. I could see it working for the separate constraint scenario, but not for the inside where scenario, which we felt much more strongly about.

[jnm2]

For flow of allow/allows, I can think of two conceptualizations that make sense to me when reading aloud:

1. "where T allows ref struct": T is the subject
2. "where [there is a] T, allow ref struct": this is either imperative, or "[we/I] allow"

The first form would be read without a pause, and the second form would be read with a pause at the comma.

But now let's consider where T : class:

1. 'where T is [a] class": T is the subject
2. 'where [there is a] T, [it must be a] class": this is no longer imperative or using "we/I"
   • or, 'where [there is a] T, [require it to be a] class": this is either imperative or "[we/I require]"

The thing that feels the most streamlined and least contrived to me is strategy 1.

[HaloFour]

Probably important to look at the "anti-constraint" in the context of being combined with other constraints as well, as I can see that being a common use case (particularly with specific interfaces):

where T : allows ref struct, IDisposable
// or
where T : allows ref struct, struct, IDisposable
// or
where T : struct, allows ref struct, IDisposable

[TahirAhmadov]

I think this is important, actually. I think it should be:

where T : struct, IDisposable; allows ref struct
// or
where T : struct, IDisposable, allows ref struct

[HaloFour]

From the proposed spec, it appears that this is the case and that allows clause must be the last clause. I also think this makes sense as it could be easy to confuse allows ref struct, IDisposable as the anti-constraint also applying to IDisposable.

[huoyaoyuan]

As a non-fusional language speaker, allow vs allows is totally nothing to me. Personally I prefer allow.

[ufcpp]

Come to think of it, C# doesn't have a keyword with s of the third person singular, while Java has implements and throws.

[alrz]

anti-constraint

It is true that this is an anti-constraint - allowing more types to be used rather than less, but it still limits the lifetime? I remember a proposal for lifetime annotations, isn't that going to happen? (even as a subset, but I think that could drive the syntax form)

cannot participate in methods that take IReadOnlyList<T>, IEnumerable<T>

The proposal mentions this as a motivation but this feature would not enable that unless the method takes a generic parameter. Wouldn't it make sense to wait for extensions to implement interfaces on ref structs? As per the last discussions I think they would always require a generic parameter.

I'm looking out for Span<Span<T>> support, but I think none of these would help with that? I don't know if that's even possible though.

[333fred]

I remember a proposal for lifetime annotations, isn't that going to happen?

No, we never planned to actually do that. It was a form of proof that our rules were sound.

[jubruckne]

I don’t like this syntax much. Why can we just have more flexible constraints like:

where T:struct or ref struct

and maybe in the future even like:

where T:float or int, INumber<T>
where T:struct, Vector2 or Vector3

[colejohnson66]

Short answer: because the CIL/runtime doesn't support it.

Long answer: These types of constraints are easy for dynamic languages like TypeScript, but harder to compile for. The compiler would be required to look at the list of methods available on any of the targets, then find the union of them all. Only that union subset would be available to use. IMO, it's a bad idea, as methods with the same signature can have different semantics. Interfaces are supposed to solve that issue, as an interface contract ensures implementers have the same semantics.

Is it possible? Sure. But will it ever happen? Doubt it. Overloads and where T:IFace exist, and both are the recommended way to handle these situations.

[HaloFour]

Another possible "anti-constraint" that came up on Discord was one that, when combined with the struct constraint, would permit a nullable value type (e.g. int?) to be the generic type argument. Seems the runtime already supports this via existing combinations of constraints but C# has never exposed it.

/cc @IS4Code

[Ghost4Man]

The "2023" in the title (LDM Notes for February 26th, 2023) is a typo, right?

[333fred]

Yes, thanks.