84 lines
4.1 KiB
Markdown
84 lines
4.1 KiB
Markdown
|
|
# C# Language Design Notes for September 24, 2018
|
|
|
|
## Agenda
|
|
|
|
F#/C# combined LDM
|
|
|
|
Two primary goals:
|
|
|
|
1. What new C# features are going to require work to get F# support?
|
|
2. How can the design of C# features play well with the broader .NET environment?
|
|
|
|
## Discussion
|
|
|
|
First, which proposed C# 8.0 features may need interop work in F#?
|
|
|
|
- [**Nullable reference types**](https://github.com/dotnet/csharplang/issues/36)
|
|
- This is by far the top priority
|
|
- F# will need to recognize C# nullability attributes and possibly
|
|
emit them itself
|
|
- [`params Span<T>`](https://github.com/dotnet/csharplang/issues/1757)
|
|
- Consumption is probably more important than production
|
|
- Need to make sure F# compiler doesn't choke on a ParamArrayAttribute on
|
|
a type other than array
|
|
- [Slicing/Range](https://github.com/dotnet/csharplang/issues/185)
|
|
- There should probably be a way to convert from F# to C# range/index
|
|
- [Records](https://github.com/dotnet/csharplang/issues/39)
|
|
- Significant work if this actually makes it into C# 8.0
|
|
- [UTF8 string literals](https://github.com/dotnet/csharplang/issues/184)
|
|
- Probably more work in language parity, specifically on F# usage of the
|
|
UTF8 string type itself
|
|
- [Default interface methods](https://github.com/dotnet/csharplang/issues/52)
|
|
- As currently spec'd, F# should at least be able to implement interfaces
|
|
with default implementations
|
|
- Open question as to how much consumption or production will be supported
|
|
in F# if C# goes ahead with the current design
|
|
- [Pattern-based using](https://github.com/dotnet/csharplang/issues/1174)
|
|
- We think F# already supports this. No work to do here
|
|
- [Async streams (IAsyncEnumerable)](https://github.com/dotnet/csharplang/issues/43)
|
|
- Probably need a helper method to convert from `IAsyncEnumerable` to F# AsyncSeq,
|
|
but since `Task` doesn't yet have first-class support, this is not the highest
|
|
priority
|
|
- [Native-sized integers](https://github.com/dotnet/csharplang/issues/435)
|
|
- Possibly some codegen support for whatever we do here
|
|
- [Readonly members on structs](https://github.com/dotnet/csharplang/issues/1710)
|
|
- Probably no work on the consumption side, but work would be required if
|
|
F# wanted to allow declaring them
|
|
|
|
Second, how should interop with other .NET languages impact C# language design?
|
|
|
|
### Nullable reference types
|
|
|
|
This is both the biggest item and also the most likely to ship in C# 8.0.
|
|
Right now, there's no mechanism for other types to be treated with the same
|
|
nullability rules provided via the C# nullable reference type feature.
|
|
Specifically, there's the question of how F#'s `Option` type will
|
|
inter-operate with C# nullable reference types. At the moment we don't have
|
|
any design to let arbitrary types to be treated as "nullable" wrappers, but
|
|
we do have a proposal to allow the `Nullable<T>` type to opt-in to nullable
|
|
reference type behaviors (https://github.com/dotnet/csharplang/issues/1865).
|
|
We're considering broadening this to other nullable wrapper types. This
|
|
may also affect our future discriminated union design.
|
|
|
|
The other question is if we want to explore a different way of representing
|
|
nullable reference types in the CLR. Right now the proposal is to do this
|
|
entirely using attributes and not treat these as different types in C#. If
|
|
we did want to treat them as different types, CLR work should be considered.
|
|
|
|
### Default implementations in interfaces
|
|
|
|
We went very far down one specific design strategy (traits). Let's come up
|
|
for air and see if we want to explore any other points in the design space.
|
|
We should also take into account our proposals around type classes
|
|
(https://github.com/dotnet/csharplang/issues/110).
|
|
|
|
### Discriminated unions
|
|
|
|
It's not on the list for C# 8.0, but when we get around to it we should
|
|
explore code generation strategies with the CLR to see how we could get the
|
|
most efficient type switching implementation. F# also notes that they don't
|
|
encourage using discriminated unions in public APIs due to the risk of
|
|
breaking changes from exhaustiveness checking. We should consider whether we
|
|
want the same restriction or provide some support for versioned discriminated
|
|
unions. |