LDM Notes for January 22nd, 2024

[MadsTorgersen]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-01-22.md

Agenda

• Ref struct interfaces
• Interceptors

[Captain-Quack]

Are there any security concerns around interceptors? From the way I interpreted their original description, it seems like a malicious programmer could use them to hijack the definition of an internal function.

[CyrusNajmabadi]

@Captain-Quack It's the same as adding any nuget package already (which can already intercept and change everything your build does).

[TonyValenti]

With ref strict, I'm not a fan of the allows syntax but do like combining it with where.

I suggest allowing a : ref struct syntax and also an OR operator. Any of the following would become valid:

Where T : class

Where T : ref struct

Where T : class or ref struct

[CyrusNajmabadi]

Note: the syntax side of this is very up for grabs right now. I, for one, view type-parameters as starting in a default state. with where T just being a way of saying "here is deviation info for that type-parameter". That info can be contraining info, or it can be easing info :)

In practice, i think this will be niche enough to not be fine to reuse the same syntax for both. (But that's just me).

[HaloFour]

I can see that, at the same time I think it might be very confusing given how differently constraints and anti-constraints work. It might be very strange that a method with a constraint where T : ref struct allows for reference types to be used as the type parameter, but that is the case (unless I'm misinterpreting something?). I also expect that the combination of struct and interface constraints with the ref struct anti-constraint would be somewhat common.

[TonyValenti]

My reasoning is the same as @CyrusNajmabadi

I also agree that only stating : ref struct should actually only allow ref structs and not classes. This is why I added OR in my suggestion.

[CyrusNajmabadi]

Like with some where clauses, I think others can be redundant. For example, if I have struct, I don't need to say new(). I would expect similar with red structs.

[HaloFour]

The ref struct anti-constraint isn't supposed to prevent you from using reference types, though. It's supposed to indicate that it's safe to use a ref struct as the type parameter, but that doesn't preclude wanting to use a normal struct or a reference type as the type parameter. That's why it doesn't make sense as a constraint with constraint syntax.

That's the whole point. An "anti-constraint" widens what you're allowed to use as the type parameter, by limiting what the declared member is allowed to do with the type parameter.

[RenderMichael]

When it comes to the “unknown unknowns” with genetics, I think bridging generic constraints is the big one. Especially for LINQ, maybe the Select method can look like

public static IEnumerable<TTo> Select<TFrom, TTo>(this IEnumerable<TFrom> values, Func<TFrom, TTo> selector)
    allow T : stackonly,
    allow T : stackonly
{
    if (TFrom is stackonly || TTo is stackonly)
    {
        return StackOnlySelect(values, selector);
    }
    return ExistingSelectImplementation(values, selector);
}

The syntax is my personal strawman but the important thing is what this lets us do. This will allow stack-only types to participate in LINQ and in the overwhelming majority of generic methods or types, as long as a stack-only implementation is somehow possible.

[RenderMichael]

The syntax seems to be a big source of bikeshedding, I’d like to propose a “nuclear option” which is the least obstructive:

public void <[AllowRefStructs] T> M() { }

The LDM mentioned leaving room for future allow constraints, so this can instead take an enum:

public void <[GenericAllows(AllowConstaints.RefStructs)] T> M() { }

Attribute name itself is up for discussion of course but I haven’t seen anyone bring up this approach. There’s plenty of prior art for making attributes affect the language, such as [Flags].

[RenderMichael]

That said, this is a very verbose syntax, even if something like #2926 gets implemented in the future. However, this is an issue faced by the main syntax proposals so far. In fact, requiring something as long as allow{s} T : ref struct basically guarantees that a separate line is needed; doubly so if the T has any constraints as well.

It has been said in the LDM notes that the vast majority of BCL generic methods should allow this "constraint": if this syntax is too verbose, then it could mean many thousands of LOC added to the BCL as well as (in my opinion) decreased clarity.

[hez2010]

This blocks the future ability of doing something like:

public void Foo<T, U> M() where T : IFoo allows U { } // note that an open type parameter cannot be used in attributes

[RenderMichael]

What’s U here? A type, or a type of type?

The suggestion for enum is because the contents of allows is a concrete set, in this feature consisting only of ref struct. Even if other anti-constraints are added, the list is finite and known.

Given U is a well-known anti-constraint, you would write:

public void Foo<[GenericAllows(AllowTypes.U)] T, U> M() where T : IFoo { }

[yaakov-h]

We discussed where we would add the allow T : ref struct anti-constraint in our existing libraries. The answer is, probably nearly all our core abstractions.

Does this mean that adding (and perhaps removing) this modifier would not be a binary breaking change?

[MauNguyenVan]

Sorry if i wrong,
Use where T : ref struct and where T : allow ref struct it seem the same meaning.
Why we don't use where T : ref struct

[KennethHoff]

By default, a generic allows "everything", and a contraint like for example where T: class contraints that to now exclusively allow classes (no more structs). Everything that can be used in a constrained generic can also be used in an unconstrained generic. ref structs cannot be used in unconstrained generics, hence the new concept of an "anti-constraint".

[TonyValenti]

The ops idea was that:
Allow T : ref struct

Is basically taking the default set of constraints and subtracting a condition from them.

I personally think this is confusing because there is additive and subtractive logic going on. The fact that it is called an "Anti-constraint" .

I think it is easier to think of different sets of constraints that are either unioned or intersected together.

Where T : class //only allow classes

Where T : ref struct //only allow ref structs

Where T : class or ref struct //allow classes or ref structs

When or is used in a constraint, it would denote the union of the "class" set of constraints and the "ref struct" set of constraints.

[TonyValenti]

@KennethHoff -
Today A generic allows everything that is not a ref struct.

[KennethHoff]

@TonyValenti I know; That's what I said(?)

[...] ref structs cannot be used in unconstrained generics, hence the new concept of an "anti-constraint".

[HaloFour]

Today A generic allows everything that is not a ref struct.

And static classes. And by-ref types. And pointers. There are other scenarios that could potentially benefit from anti-constraints, given language and/or runtime support.

IMO, the suggested union syntax is even more verbose, as adding the anti-constraint allow T : ref struct by itself would always be equivalent to where T : class or struct or ref struct.