# C# Language Design Notes for Feb 21, 2017

## Agenda

We triaged some of the [championed features](https://github.com/dotnet/csharplang/issues?q=is%3Aopen+is%3Aissue+label%3A%22Proposal+champion%22), to give them a tentative milestone and ensure they had a champion.

As part of this we revisited potential 7.1 features and pushed several out.

1. Implicit interface implementation in Visual Basic *(VB 16)*
2. Delegate and enum constraints *(C# X.X)*
3. Generic attributes *(C# X.0 if even practical)*
4. Replace/original *(C# X.0 if and when relevant)*
5. Bestest betterness *(C# 7.X)*
6. Null-coalescing assignments and awaits *(C# 7.X)*
7. Deconstruction in from and let clauses *(C# 7.X)*
8. Target-typed `new` expressions *(C# 7.X)*
9. Mixing fresh and existing variables in deconstruction *(C# 7.1)*
10. Implementing `==` and `!=` on tuple types *(C# 7.X)*
11. Declarations in embedded statements *(No)*
12. Field targeted attributes on auto-properties *(C# 7.1)*


# Implicit interface implementation in Visual Basic
[Champion "Implicit interface implementation"](https://github.com/dotnet/vblang/issues/38)

This long-requested feature in VB would also help deal with problems related to [default implementations of interface members](https://github.com/dotnet/csharplang/issues/52).

## Conclusion
Candidate for VB 16.


# Delegate and enum constraints
[Champion "Generic constraint `delegate` (or allow `System.Delegate` as a constraint)"](https://github.com/dotnet/csharplang/issues/103)

[Champion "Generic constraint `enum` (or allow `System.Enum` as a constraint)"](https://github.com/dotnet/csharplang/issues/104)

This is a common request. Could

- semantically require an actual delegate/enum or just allow the base class
- syntactically show up as either the base class or the keyword

For delegates we need to consider how to deal with `MulticastDelegate`.

## Conclusion
Candidates for a minor C# version.


# Generic attributes
[Champion "Allow Generic Attributes"](https://github.com/dotnet/csharplang/issues/124)

Even though this would work in principle, there are bugs in most versions of the runtime so that it wouldn't work correctly (it was never exercised).

We need a mechanism to understand which target runtime it works on. We need that for many things, and are currently looking at that. Until then, we can't take it.

## Conclusion
Candidate for a major C# version, if we can make a sufficient number of runtime versions deal with it.


# Replace/original
[Champion "Replace/original and code generation extensions"](https://github.com/dotnet/csharplang/issues/107)

If there's renewed investment in source generators, we'll add this, but this is not driven from the language end.

## Conclusion
Candidate for a major C# version, if and when source generators or similar efforts take place.


# Bestest betterness
[Champion "Bestest Betterness"](https://github.com/dotnet/csharplang/issues/98)

We want to do it, but not low-hanging enough for C# 7.1 time frame.

## Conclusion
Candidate for a minor C# release in the 7.X wave.


# Null-coalescing assignments and awaits
[Champion "Null-coalescing assignments"](https://github.com/dotnet/csharplang/issues/34)

[Champion "Null-conditional await"](https://github.com/dotnet/csharplang/issues/35)

These need a little more design work and general bake time than what 7.1 allows.

`await?` is an odd kind of keyword, but changing `await` to not throw on null may also be an issue. Thought needed.

## Conclusion
Candidate for a minor C# release in the 7.X wave.


# Deconstruction in from and let clauses
[Champion "deconstruction in from and let"](https://github.com/dotnet/csharplang/issues/189)

Too many worms in the can for 7.1.

## Conclusion
Candidate for a minor C# release in the 7.X wave.


# Target-typed `new` expressions
[Champion "Target-typed `new` expression"](https://github.com/dotnet/csharplang/issues/100)

Links well with target typed `default` expressions, but too much design and potential fallout for 7.1. Interaction with anonymous objects as well.

## Conclusion
Candidate for a minor C# release in the 7.X wave.


# Mixing fresh and existing variables in deconstruction
[Champion "Mix Declarations and Variables in Deconstruction"](https://github.com/dotnet/csharplang/issues/125)

This rounds out the C# 7.0 experience, and was a late design change we didn't get to implementing.

May lead to occasional confusion, as in `M((int x, y) = e)` (declaring `y`)? We are OK with that.

## Conclusion
Candidate for C# 7.1.


# Implementing `==` and `!=` on tuple types
[Champion "Support for == and != on tuple types"](https://github.com/dotnet/csharplang/issues/190)

There's design work. It's not just call `.Equals` recursively.

`==` today works between int and byte, for instance. We should probably make `(i1, i2) == (b1, b2)` work with that same equality.

Also for generics, for a type parameter `T` and a `t` of that type, we should allow `(t, i) == (null, 0)` by recursively applying the special "compare to null" semantics of equality over type parameters of C# today.

Too big for 7.1.

## Conclusion
Candidate for a minor C# release in the 7.X wave.


# Declarations in embedded statements

Now that you can declare expression variables in an embedded statement, it's odd that old-fashioned declaration statements are forbidden in an embedded position (such as an if-branch, for instance). However, now that you can use a discard instead of a dummy variable declaration, the motivating scenario also goes away.

## Conclusion
Let's not do it.


# Field targeted attributes on auto-properties
[Champion "Auto-Implemented Property Field-Targeted Attributes"](https://github.com/dotnet/csharplang/issues/42)

Technically a breaking change, since the field target is already permitted today, but ignored. We don't expect anyone to be relying on this, though!

## Conclusion
Candidate for 7.1.