
# 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:

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

The attribute-like syntax would be turned into the `modreq`s 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.

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

and registration like `INotifyPropertyChanged`

```C#
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.