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