119 lines
No EOL
4.3 KiB
Markdown
119 lines
No EOL
4.3 KiB
Markdown
|
|
# 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. |