C# Language Design Notes for September 24, 2018

Agenda

F#/C# combined LDM

Two primary goals:

What new C# features are going to require work to get F# support?
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
- This is by far the top priority
- F# will need to recognize C# nullability attributes and possibly emit them itself
params Span<T>
- 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
- There should probably be a way to convert from F# to C# range/index
Records
- Significant work if this actually makes it into C# 8.0
UTF8 string literals
- Probably more work in language parity, specifically on F# usage of the UTF8 string type itself
Default interface methods
- 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
- We think F# already supports this. No work to do here
Async streams (IAsyncEnumerable)
- 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
- Possibly some codegen support for whatever we do here
Readonly members on structs
- 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.

4.1 KiB Raw Permalink Blame History