csharplang/meetings/2020/LDM-2020-04-01.md

C# Language Design Meeting for April 1, 2020

Agenda

1. Function pointer calling conventions

2. field keyword in properties

Discussion

Function Pointers

There are a few open issues and proposals for generalization of function pointers based on new runtime features.

https://github.com/dotnet/csharplang/issues/3324

NativeCallableAttribute

The attribute already exists in the CLR, and allows for specifying a calling convention other than managed (which means that it can't be called from C#, but could be used from function pointers).

The question is what level of support we want to provide in the language for this attribute.

Since the runtime behavior is to crash if the method is called incorrectly (meaning, invoked at all from C# if not through a function pointer), we almost certainly want to recognize the attribute's existence and provide errors for incorrect usage.

We considered more restrictions than the ones mentioned in the issue (only usable in function pointers, parameters must be blittable, must be static) like restricted accessibility or special syntax. The consensus is that is too much work for a small feature.

Conclusion

NativeCallableAttribute should be recognized and the restrictions are accepted, with the addition that generics are also prohibited in the method and all containing types, recursively, and delegate conversion is also prohibited.

Supporting extra calling conventions

The existing proposal mandates that the only the existing calling conventions are supported. We previously said we'd consider new calling conventions when they were proposed by the runtime. We now have proposals about some likely new calling convention from the runtime.

The proposal is that the "calling convention" syntax in function pointers could be a general identifier, and legal values for the runtime would be determined by name matching against type names starting with CallConv in a particular namespace, and passing through Unicode lower-case mapping.

Conclusion

Accepted.

Attributes on function pointer types

The syntax is getting a bit verbose, but allowing an extra axis for customization seems like the simplest extension of function pointers that provides the level support that the runtime may need in the future.

Currently our favored syntax is:

delegate* cdecl[SuppressGCTransition, MyFuncAttr]<void> ptr;

The attribute-like syntax would be turned into the modreqs on the function pointer type that would be used by the runtime to encode special calling behavior. These would also effectively be different types at the C# level and would not have implicit conversions between them.

Conclusion

Accepted, assuming there are no problems in implementation.

field keyword in properties

Over the years there have been many requests for similar features, e.g. https://github.com/dotnet/csharplang/issues/140

Maybe the simplest version is that there is a contextual identifier, e.g. field, which refers to an implicit backing field of the property. This seems useful, but a big limitation is that the backing field of the property must have the same type as the property. If lazy initialization is a common case, that seems likely to require differing property types, as the backing field would often be nullable, but the initialized field would be not nullable.

On the other hand, biting off too much in a single feature may delay simple scenarios unnecessarily. Should we try to address the simplest scenarios first, and leave more complex scenarios for later? In this case we probably need to find what scenarios are served by that design. Two things that are recognized are simple validation, e.g.

public int PositiveValue
{
    get => field;
    set
    {
         if (value < 0)
            throw new ArgumentException("Cannot be negative")
        field = value;
    }
}

and registration like INotifyPropertyChanged

public int P
{
    get => field;
    set
    {
        PropertyChanged();
        field = value;
    }
}

Let's confirm that these scenarios are the ones most commonly requested and that they aren't addressed or modified by any of the other scheduled language features, e.g. source generators for INotifyPropertyChanged. From there we can discuss the specific proposal with a better understanding of the problem and solution space.