C# Futures

Gerade erst wurde C# 6 final freigegeben, da macht sich das C# Design Team bereits Gedanken um die nächste Version… oder besser gesagt um die nächsten Versionen. Doch so richtig startete die Diskussion um C# 7 öffentlich bereits im Januar, als die ersten C# Design Notes auf Github veröffentlicht wurden… und das ist wahrscheinlich das größte Novum, welches auch die Zukunft von C# beeinflussen wird: das C#-Team macht seine Vorschläge für Spracherweiterungen öffentlich und jeder kann dann an der Diskussion um diese Design-Features teilnehmen. Natürlich gibt es immernoch ein Microsoft-Team, das über die generelle Richtung und die konkrete Umsetzung entscheidet, ein jeder kann sich aber in die Entscheidungsfindung mit einbringen. Darüber hinaus kann jeder auf UserVoice auch eigene Vorschläge für Spracherweiterungen einreichen.

Neben den Design Notes gibt es auf Github auch andere Dokumentation, die den Design-Prozess transparent machen und verdeutlichen, was für C# 7 zu erwarten ist. Z.B. gibt es eine C# 7 Work List of Features, auf der mögliche Features priorisiert aufgeführt sind. Von großem Interesse für die Umsetzung sind laut dieser Liste:

• Tuples (Proposal: #347)
• Pattern matching (Proposal: #206)
• Records / algebraic data types (Proposal: #206)
• Nullability tracking (Proposal: #227)
• Async streams and disposal (Proposals: #114, #261)
• Strongly typed access to wire formats (See #3910)

Auf einige dieser Punkte (pattern matching, nullability, …) und noch mehr geht folgendes neues Video auf Channel9 ein, wo sie von Mads Torgersen erläutert werden:

Pattern Matching

Ein großes Thema in C# 7 könnte bzw. wird Pattern Matching werden. Genereller Hintergrund dabei stellt u.a. die funktionale Programmierung dar, bei der Pattern Matching zur Auswahl von Funktionalität eine zentrale Rolle spielt. Funktionale Aspekte haben immer mehr Einfluss auf C# erhalten und mit Pattern Matching könnte der nächste große Block ins Haus stehen. Generelles Ziel des Pattern Matching in C# wird sein, einen funktionalen Code-Block anhand flexibler Kriterien ausführen zu können. Solche Kriterien könnten z.B. ein Datentyp oder ein Objektzustand sein… selbst Zustandsautomaten ließen sich damit elegant abbilden, wenn man als Input für das Matching den aktuellen Zustand und eine Eingabe ansieht (Pseudocode nachfolgend):

match (state, input)
{
    (running, "shutdown") => ...
    (running, "suspend") => ...
    (standby, "resume") => ...
    default => ...
}

Wie cool wäre es, so etwas in C# abbilden zu können? Durch Pattern Matching könnten viele verschachtelte if-Blöcke bald der Vergangenheit angehören, die Programmierung selbst würde deutlich deklarativer werden und somit Regelbeschreibungen viel besser und übersichtlicher abbilden als iterativer Code. Ob für eine solche Funktionalität das switch-Statement erweitert wird oder es eine neue Syntax wie z.B. einen match-Operator geben wird, steht noch nicht fest.

Tuple

Ein weiteres sehr interessantes Thema für mich stellt die Erweiterung von Tuples dar. Generell geht es dabei um eine stärkere Ausdrucksmöglichkeit für Tuple in C#, sodass sie sinnvoller und sauberer z.B. als Rückgabewerte von Methoden verwendet werden können. Persönlich mag ich die aktuelle Implementierung Tuple<> nicht besonders. Möchte ich z.B. einen string und ein int aus einer Methode zurückgeben, so bin ich darauf angewiesen Tuple<string, int> zu verwenden, muss dann in der Auswertung aber mit .Item1 und .Item2 darauf zugreifen, was aus meiner Sicht eine furchtbare Lesbarkeit meines Codes ergibt.

In C# 7 könnte durch eine neue Tuple-Syntax Schluss damit sein. Die Diskussion darüber ist schon weit fortgeschritten und so wird es wohl möglich sein, Tuple verkürzt zu definieren und den einzelnen Bezeichnern auch Namen zu geben:

private (string x, int y) MyMethod()
{
    return ("Hello", 1);
}

...

(string, int) myTuple = MyMethod();
string x = myTuple.x;

Nullability

Als drittes Thema finde ich die angedachte Möglichkeit interessant ausdrücken zu können, ob ein Wert bzw. eine Klasseninstanz null sein kann oder nicht. Derzeit muss man als Nutzer einer Komponente immer damit rechnen, dass ein Rückgabewert null sein kann. Das erfordert oftmals unnötige if-Abfragen, die den Code verschmutzen und die eigentliche Businesslogik überlagern. Hier diskutieren das C# Design Team und die Community derzeit, wie man sprachlich ausdrücken kann, dass ein Wert null sein kann bzw. eben nicht. Eine Idee ist die Einführung eines !-Operators um auszudrücken, dass eine Variable einen Wert ungleich null haben muss, z.B. mit string! value. Das C# Design Team möchte aber lieber keinen neuen Operator einführen, da es sonst mit dem bisherigen ?-Operator drei Wege geben würde, Variablen bzw. ihre Nullability auszudrücken: string value, string? value und string! value. Hier würde es prinzipiell ausreichen, string value und string? value zu nehmen und vom Standardfall auszugehen, dass ein Wert nicht null ist, wenn er nicht mit dem ?-Operator versehen ist. Ein wichtiger Punkt ist hierbei auch die Beachtung von Abwärtskompatibilität, was vom C#-Team berücksichtigt wird und sich evtl. in Compiler-Warnungen statt harten Fehlern niederschlägt. Aber dies ist noch Stand der aktuellen Diskussion.

Ich finde die angestrebten Erweiterungen der Sprache sehr gut. Sowohl Pattern Matching als auch die neue Tuple-Syntax und die angedachte Nullability-Behandlung erlauben mir eine viel stärkere Ausdrucksmächtigkeit meiner angestrebten Logik, ohne in überflüssigen if-Wasserfällen zu versinken. Das hält den Code sauber und ausdrucksstark! Weitere Themen sind z.B. eine Generalisierung des is-Operators (zur Vermeidung zusätzlicher Casts bzw. if-Abfragen) oder auch die Übertragung des Konzepts der Extension Methods auf weitere Klassen-Member, z.B. auf Extension Properties. Man darf auf jeden Fall gespannt sein!