Convert Figma logo to code with AI

dotnet logocsharplang

The official repo for the design of the C# programming language

11,477
1,018
11,477
484

Top Related Projects

100,112

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

48,780

The Kotlin Programming Language.

96,644

Empowering everyone to build reliable and efficient software.

123,517

The Go programming language

67,285

The Swift Programming Language

63,003

The Python programming language

Quick Overview

The dotnet/csharplang repository is the official home for C# language design and specification. It contains proposals, discussions, and documentation related to the evolution of the C# programming language. This repository serves as a central hub for the C# community to participate in the language's development process.

Pros

  • Transparent language design process, allowing community involvement
  • Comprehensive documentation of language features and proposals
  • Regular updates and active maintenance by the C# language team
  • Serves as a valuable resource for understanding C# language evolution

Cons

  • Can be overwhelming for newcomers due to the technical nature of discussions
  • Some proposals may take a long time to be implemented or rejected
  • Occasional heated debates on controversial language features
  • Requires a deep understanding of C# to fully engage in discussions

Note: As this is not a code library, the code examples and getting started sections have been omitted.

Competitor Comparisons

100,112

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

Pros of TypeScript

  • Broader ecosystem and community support
  • More flexible type system with advanced features like union types and generics
  • Better tooling and IDE support for JavaScript-based environments

Cons of TypeScript

  • Compilation step required, which can slow down development
  • Learning curve for developers new to static typing in JavaScript
  • Potential for type-related errors that don't exist in plain JavaScript

Code Comparison

TypeScript:

interface Person {
  name: string;
  age: number;
}

function greet(person: Person): string {
  return `Hello, ${person.name}!`;
}

C# (csharplang):

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
}

public string Greet(Person person) => $"Hello, {person.Name}!";

Both TypeScript and csharplang repositories focus on language design and evolution. TypeScript aims to add optional static typing to JavaScript, while csharplang is dedicated to the development of the C# language. TypeScript offers more flexibility for web development, whereas C# provides stronger type safety and performance for a wider range of applications. The choice between them often depends on the specific project requirements and the development ecosystem.

48,780

The Kotlin Programming Language.

Pros of kotlin

  • More concise syntax, reducing boilerplate code
  • Better null safety with built-in null-checking mechanisms
  • Seamless interoperability with Java, allowing gradual adoption

Cons of kotlin

  • Slower compilation times compared to C#
  • Smaller ecosystem and community support
  • Steeper learning curve for developers coming from C#

Code Comparison

kotlin:

fun main() {
    val numbers = listOf(1, 2, 3, 4, 5)
    val doubled = numbers.map { it * 2 }
    println(doubled)
}

csharplang:

using System;
using System.Linq;

class Program {
    static void Main() {
        var numbers = new[] { 1, 2, 3, 4, 5 };
        var doubled = numbers.Select(x => x * 2);
        Console.WriteLine(string.Join(", ", doubled));
    }
}

The kotlin example demonstrates its more concise syntax, with less boilerplate code and implicit typing. The csharplang example shows C#'s explicit typing and use of LINQ for similar functionality. Both languages offer powerful features for working with collections, but kotlin's syntax is generally more compact.

96,644

Empowering everyone to build reliable and efficient software.

Pros of rust

  • Rust offers memory safety without garbage collection, providing better performance and control over system resources
  • The Rust ecosystem has a more modern package manager (Cargo) and build system
  • Rust has a stronger focus on systems programming and low-level control

Cons of rust

  • Steeper learning curve due to concepts like ownership and lifetimes
  • Smaller ecosystem and community compared to C#
  • Longer compilation times, especially for large projects

Code comparison

Rust:

fn main() {
    let numbers = vec![1, 2, 3, 4, 5];
    let sum: i32 = numbers.iter().sum();
    println!("Sum: {}", sum);
}

C# (csharplang):

class Program {
    static void Main() {
        var numbers = new List<int> { 1, 2, 3, 4, 5 };
        var sum = numbers.Sum();
        Console.WriteLine($"Sum: {sum}");
    }
}

Both examples demonstrate a simple sum operation on a list of integers, showcasing similar functionality but with language-specific syntax and idioms. Rust's approach is more explicit about types and uses iterators, while C# leverages LINQ for a more concise syntax.

123,517

The Go programming language

Pros of go

  • Simpler language design with fewer features, leading to faster compilation and easier learning curve
  • Built-in concurrency support with goroutines and channels
  • Faster execution speed for certain types of applications

Cons of go

  • Less extensive standard library compared to C#
  • Limited generics support (introduced in Go 1.18, but still not as comprehensive as C#)
  • Lack of some advanced features like operator overloading and attributes

Code comparison

go:

func main() {
    go func() {
        fmt.Println("Hello from goroutine")
    }()
    fmt.Println("Hello from main")
}

csharplang:

static async Task Main()
{
    await Task.Run(() => Console.WriteLine("Hello from task"));
    Console.WriteLine("Hello from main");
}

The go example demonstrates the simplicity of creating and running a goroutine, while the csharplang example shows the use of async/await for concurrent execution. Both achieve similar results, but go's syntax is more concise for this particular use case.

67,285

The Swift Programming Language

Pros of swift

  • Open-source development with a more transparent evolution process
  • Faster release cycles and more frequent updates
  • Stronger focus on modern language features and syntax improvements

Cons of swift

  • Smaller community and ecosystem compared to C#
  • Limited cross-platform support outside of Apple ecosystems
  • Less mature tooling and IDE integration

Code Comparison

Swift:

let numbers = [1, 2, 3, 4, 5]
let doubled = numbers.map { $0 * 2 }
print(doubled)

C# (csharplang):

var numbers = new[] { 1, 2, 3, 4, 5 };
var doubled = numbers.Select(x => x * 2);
Console.WriteLine(string.Join(", ", doubled));

Additional Notes

  • swift is the primary repository for the Swift programming language, while csharplang focuses on C# language design proposals.
  • swift includes the compiler, standard library, and core components, whereas csharplang is mainly for language specification and feature discussions.
  • Both projects are open-source, but swift has a more active community-driven development process.
  • csharplang benefits from Microsoft's extensive resources and the broader .NET ecosystem.
  • swift's development is closely tied to Apple's platforms, while C# has a wider range of applications across different operating systems.
63,003

The Python programming language

Pros of cpython

  • Extensive standard library with batteries-included philosophy
  • Simpler syntax, making it easier for beginners to learn
  • Dynamic typing allows for more flexible and rapid development

Cons of cpython

  • Generally slower execution compared to compiled languages
  • Global Interpreter Lock (GIL) limits true multi-threading capabilities
  • Less strict typing can lead to runtime errors

Code Comparison

cpython:

def greet(name: str) -> str:
    return f"Hello, {name}!"

print(greet("World"))

csharplang:

public static string Greet(string name)
{
    return $"Hello, {name}!";
}

Console.WriteLine(Greet("World"));

Key Differences

  • cpython uses indentation for code blocks, while csharplang uses curly braces
  • cpython has optional type hints, whereas csharplang has mandatory static typing
  • cpython's syntax is generally more concise compared to csharplang
  • csharplang requires explicit method declarations (public static), while cpython does not

Both repositories are essential for their respective languages, with cpython being the reference implementation for Python and csharplang focusing on C# language design and evolution.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

C# Language Design

Join the chat at https://gitter.im/dotnet/csharplang Chat on Discord

Welcome to the official repo for C# language design. This is where new C# language features are developed, adopted and specified.

C# is designed by the C# Language Design Team (LDT) in close coordination with the Roslyn project, which implements the language.

You can find:

If you discover bugs or deficiencies in the above, please leave an issue to raise them, or even better: a pull request to fix them.

For new feature proposals, however, please raise them for discussion, and only submit a proposal as a pull request if invited to do so by a member of the Language Design Team (a "champion").

Discussions

Debate pertaining to language features takes place in the form of Discussions in this repo.

If you want to suggest a feature, discuss current design notes or proposals, etc., please open a new Discussion topic.

Discussions that are short and stay on topic are much more likely to be read. If you leave comment number fifty, chances are that only a few people will read it. To make discussions easier to navigate and benefit from, please observe a few rules of thumb:

  • Discussion should be relevant to C# language design. If they are not, they will be summarily closed.
  • Choose a descriptive topic that clearly communicates the scope of discussion.
  • Stick to the topic of the discussion. If a comment is tangential, or goes into detail on a subtopic, start a new discussion and link back.
  • Is your comment useful for others to read, or can it be adequately expressed with an emoji reaction to an existing comment?

Language proposals which prevent specific syntax from occurring can be achieved with a Roslyn analyzer. Proposals that only make existing syntax optionally illegal will be rejected by the language design committee to prevent increased language complexity.

Proposals

Once you have a fully fleshed out proposal describing a new language feature in syntactic and semantic detail, please open an issue for it, and it will be labeled as a Proposal. The comment thread on the issue can be used to hash out or briefly discuss details of the proposal, as well as pros and cons of adopting it into C#. If an issue does not meet the bar of being a full proposal, we may move it to a discussion, so that it can be "baked" further. Specific open issues or more expansive discussion with a proposal will often warrant opening a side discussion rather than cluttering the comment section on the issue.

When a member of the C# LDM finds that a proposal merits discussion, they can Champion it, which means that they will bring it to the C# Language Design Meeting. If the LDM decides to work on adopting the feature, the proposer, the champion and others can collaborate on adding it as a document to the Proposals folder, where its evolution can be tracked over time.

Design Process

Proposals evolve as a result of decisions in Language Design Meetings, which are informed by discussions, experiments, and offline design work.

In many cases it will be necessary to implement and share a prototype of a feature in order to land on the right design, and ultimately decide whether to adopt the feature. Prototypes help discover both implementation and usability issues of a feature. A prototype should be implemented in a fork of the Roslyn repo and meet the following bar:

  • Parsing (if applicable) should be resilient to experimentation: typing should not cause crashes.
  • Include minimal tests demonstrating the feature at work end-to-end.
  • Include minimal IDE support (keyword coloring, formatting, completion).

Once approved, a feature should be fully implemented in Roslyn, and fully specified in the language specification, whereupon the proposal is moved into the appropriate folder for a completed feature, e.g. C# 7.1 proposals.

DISCLAIMER: An active proposal is under active consideration for inclusion into a future version of the C# programming language but is not in any way guaranteed to ultimately be included in the next or any version of the language. A proposal may be postponed or rejected at any time during any phase of the above process based on feedback from the design team, community, code reviewers, or testing.

Milestones

We have a few different milestones for issues on the repo:

  • Working Set is the set of championed proposals that are currently being actively worked on. Not everything in this milestone will make the next version of C#, but it will get design time during the upcoming release.
  • Backlog is the set of championed proposals that have been triaged, but are not being actively worked on. While discussion and ideas from the community are welcomed on these proposals, the cost of the design work and implementation review on these features are too high for us to consider community implementation until we are ready for it.
  • Any Time is the set of championed proposals that have been triaged, but are not being actively worked on and are open to community implementation. Issues in this can be in one of 2 states: needs approved specification, and needs implementation. Those that need a specification still need to be presented during LDM for approval of the spec, but we are willing to take the time to do so at our earliest convenience.
  • Likely Never is the set of proposals that the LDM has rejected from the language. Without strong need or community feedback, these proposals will not be considered in the future.
  • Numbered milestones are the set of features that have been implemented for that particular language version. For closed milestones, these are the set of things that shipped with that release. For open milestones, features can be potentially pulled later if we discover compatibility or other issues as we near release.

Language Design Meetings

Language Design Meetings (LDMs) are held by the LDT and occasional invited guests, and are documented in Design Meeting Notes in the meetings folder, organized in folders by year. The lifetime of a design meeting note is described in meetings/README.md. LDMs are where decisions about future C# versions are made, including which proposals to work on, how to evolve the proposals, and whether and when to adopt them.

Language Specification

It is our plan to move the C# Language Specification into Markdown, and draft it in the spec folder. The spec drafts will eventually be standardized and published by ECMA. The folder currently contains an unofficial Markdown version of the C# 6.0 specification for convenience.

Implementation

The reference implementation of the C# language can be found in the Roslyn repository. This repository also tracks the implementation status for language features. Until recently, that was also where language design artifacts were tracked. Please allow a little time as we move over active proposals.