There is also a lot of work in bringing STL types to the DRuntime (see https://github.com/dlang/druntime/pull/2310).

There is also a lot of work in bringing STL types to the DRuntime (see https://github.com/dlang/druntime/pull/2310).

+

+

All of the above examples allow to use C++ libraries from D, but it's also useful to be able to use a D library from C++. Therefore a tool, separate (using the compiler as a library) or integrated in the compiler, that can generate a C++ header for a D module would be of great value. There are a few existing attempts:

+

+

* Integrated into the compiler: https://github.com/dlang/dmd/pull/8591

+

* As a separate tool: https://github.com/thewilsonator/dtoh

D would greatly benefit by seamlessly integrating the C++ ecosystem. There are many ways to accomplish this goal and it should be discussed with the community.

D would greatly benefit by seamlessly integrating the C++ ecosystem. There are many ways to accomplish this goal and it should be discussed with the community.

Revision as of 13:10, 28 February 2019

This is the D Language Foundation's Google Summer of Code 2019 page.

If you are interested in working on a D project as part of GSoC 2019, as either a student or mentor, please contact the GSoC admins at social@dlang.org. Include "GSoC 2019" in the email subject line.

Timeline

Ideas

The D ecosystem is always in need of improvement through the revision of existing projects and the creation of new ones. The core projects like the(standard library) and the compilers (Compilers) are always in need of attention. Other important areas include GUI support, integration with other languages, improving and enhancing the tooling, IDE and editor support, and more.

Please add your project ideas to the list below, being as descriptive as you can in the summaries. Students interested in participating can use the ideas listed here as jumping off points, so the more information you provide, the easier it will be for them to get started. If your idea is particularly complex or nuanced, consider leaving contact information so that interested parties may follow up.

Graphics library for resource constrained embedded systems

Create a 2D rasterizer, rich drawing primitives, and 2D graphics library suitable for resource constrained embedded systems (e.g. ARM Cortex-M) to be used in industrial controls, home appliances, medical devices, consumer electronics, and IoT just to name a few. The end goal would be something similar to Segger's emWin. The library would be used to drive LDCs similar to https://www.adafruit.com/product/3396
Requirements:

Hardware agnostic; should simply render to a frame buffer

No dependencies (No Phobos, no C standard library, and no official D runtime).

Consider using -betterC, but a custom minimal D runtime is also a viable option

Tabular data container (data frames)

Pandas, R and Julia have made data frames very popular.
As D is getting more interest from data scientist (e.g. eBay or AdRoll) it would be very beneficial to use one language for the entire data analysis pipeline - especially considering that D (in contrast to popular languages like Python, R or Julia) - is compiled to native machine code and gets optimized by the sophisticated LLVM backend.

Minimum requirements:

conversion to and from CSV

multi-indexing

column binary operations, e.g. `column1 * column2`

group-by on an arbitrary number of columns

column/group aggregations

Proposed Project Mentor: Ilya Yaroshenko

C++ interops

There are many experiments in transparently interfacing D with C++, notably:

All of the above examples allow to use C++ libraries from D, but it's also useful to be able to use a D library from C++. Therefore a tool, separate (using the compiler as a library) or integrated in the compiler, that can generate a C++ header for a D module would be of great value. There are a few existing attempts:

D would greatly benefit by seamlessly integrating the C++ ecosystem. There are many ways to accomplish this goal and it should be discussed with the community.
Andrei already commented on the importance of a tool like Calypso in this thread:
https://forum.dlang.org/post/m9s4cd$2s1v$1@digitalmars.com

Proposed Project Mentor: Andrei Alexandrescu

Persistent Data Structures

There is an ongoing effort to reduce the reliance of Phobos on the GC but the GC is not going anywhere given that it has many advantages over manual memory management.
The community would greatly benefit from a wide range of functional programming techniques that have their roots in the usage of immutable and persistent data structures that heavily rely on the GC.
Persistent Data Structures are heavily used in Scala and Clojure and they allow the programmer to reason about interactivity, sharing and parallelism.

The focus of this project would be to create a varying range of persistent data structures (sets, vectors, maps, strings, trees, lists, etc...) that respects the range interface and the semantics of Phobos.

Language Server Protocol for D

The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto complete, go to definition, find all references etc. Adding features like auto complete, go to definition, or documentation on hover for a programming language takes significant effort. Traditionally this work had to be repeated for each development tool, as each tool provides different APIs for implementing the same feature (see the list of Editors and IDEs). Additionally as the existing tools only use `libdparse` (used in DLS and DCD), they lack the ability to perform semantic analysis on the AST and can't evaluate `mixin`'s nor D's very powerful Compile-Time Function Evaluation (CTFE).
A Language Server is meant to provide the language-specific smarts and communicate with development tools over a protocol that enables inter-process communication.
The idea behind the Language Server Protocol (LSP) is to standardize the protocol for how such servers and development tools communicate. This way, single D Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort.

Recent development in the DMD compiler made it available as a DUB library. This mean that the compiler itself can be re-used and third-party tools don't have to re-implement e.g. D's complex CTFE. This project is about using the DMD compiler as a library to implement a Language Server for D.

To work on the Mir project requires a responsible and self-motivated student.

Proposed Project Mentor: Ilya Yaroshenko

DUB: D's package manager

DUB - D's package manager - is one of the central infrastructure tools in the D world as a convenient build and package management tool for the D community.
With D gaining more and more popularity, it's also a key tool to guarantee D's further adoption.
Thus there are many great ideas to improve DUB:

support building a {snap, Debian, Arch, ...} package out of DUB package

Any of these listed DUB Enhancement Proposals (DEPs) could form the basis of a GSoC Project.

Proposed Project Mentors: Sönke Ludwig, Sebastian Wilzbach

LDC (LLVM-based D compiler)

The LDC project provides a portable D programming language compiler with modern optimization and code generation capabilities.
The ever-improving feature set of LLVM opens up many opportunities with D.
A few ideas for a potential GSoC project are:

exploiting immutability of variables (notably of structs such as string slices)

Baremetal D runtime

Many features in the standard library are implemented by using the C runtime. Reusing the rock-solid work of generations of programmers makes a lot of sense as just outputting via `printf` can be very complex. However, for embedded environments a programmer often only has a tiny amount of storage available or might not even have a C runtime available for his target.
The idea of this project is to implement the most basic parts of the runtime natively in D, s.t. bare metals programmers can just compile for their target. Implementing features natively in D also means that other targets like Web Assembly will automatically be able to use them too. Another advantage of implementing these basic building blocks in D is that one can take advantage of D's Compile-Time Function Evaluation (CTFE) and optimize the methods even further at compile-time.

Project focus:
- Implement `memcpy`, `memcmp` and similar in D (with similar performance to C)
- Implement `malloc` and similar in D (with similar performance to C)

Header generation for C/C++

With the ever-improving integration between DMD and C/C++, quite a bit of tooling has been developed to generate D header files from C or C++ projects (e.g. DStep or DPP).
However, for many projects the majority of the source code is now written in D and the reverse step is needed: an automatic way to generate C and C++ headers from a D project.
This would be very valuable for D as it could motivate inter-language projects that typically go C++-fist-with-a-D-binding to work the other way.

Jupyter notebook D kernel

The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text. Uses include: data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and much more.
Jupyter notebooks are extremely popular among data scientist as they allow interactive progress and exploring a solution step by step.
With a bit of work, a statically compiled language can be used in an interactive notebook e.g. [Cling https://blog.jupyter.org/interactive-workflows-for-c-with-jupyter-fe9b54227d92] and Go with
gophernotes.
Apart from being useful to data scientist, a Jupyter D kernel would allow an intuitive exploration of the language for newcomers and people starting with new libraries.

Functional Reactive Programming

Functional reactive programming (FRP) is a programming paradigm for reactive programming (asynchronous dataflow programming) using the building blocks of functional programming (e.g. map, reduce, filter).
The best-known FRP API is the ReactiveX API whose implementation in D this project would focus.
Note that this project is closely related to the std.eventloop project.

Proposed Project Mentors: Petar Kirov

BetterC runtime

BetterC is a subset of D which limits the feature set of D, s.t. it's even easier to migrate from C as no Garbage Collection (GC) is used anymore.
While, this feature is popular for some projects, `-betterC` today means still means a severe restriction in the amount of D features available (see the BetterC specification.
This project is about making more parts of the D runtime betterC-compatible. For example, classes could be allocated with reference-counting instead of using the GC.

Proposed Project Mentors: TBA

Java Native Interface (JNI) library

D's features allow to write cut down the boilerplate of wrapper drastically.
See the recently published excel-d for a comparison between the C++ implementation for registering a function in Excel and the D way.
Similarly a solid JNI library would open up new many new use cases and allow the Java community to profit even easier from D's features.

ORM mapping

SQLAlchemy is an object-relational mapper which provides "a full suite of well known enterprise-level persistence patterns, designed for efficient and high-performing database access, adapted into a simple and Pythonic domain language".
While there has been some attempts in implementing an ORM in D - none of these got close to the simplicity and usability of SQLAlchemy (see Database Libraries).
However, with D's CTFE queries could - like std.format's strings - already be checked at compile-time and optimizations could be be applied to the parser and serializer.

std.serialization

D has numerous serialization frameworks. From `std.json` to `std.csv` over protobuf to Vibe.d's own serialization framework.
The goal of this project is to implement a flexible (de)serialization framework that can be used as a standardized building block for various serialization related things.
One important goal would be to define how a user-specified type has to work in order to make it serializable, as well as to allow the end-user (e.g. a user of std.json) to change the serialization of third-party types that cannot themselves be modified (i.e. let them define their own policies).

Propose your own project

Do you have your own vision for improving D's success? That's great!
Are you convinced that your project helps to advance open source technology related to the D programming language?
Then simply get in touch with D's GSoC org admin (social (at) dlang (dot) org) and potential mentors for your project.