Difference between revisions of "Wish list"

From D Wiki
Jump to: navigation, search
(→‎Other questionable modules: fixed list formatting)
(→‎std.decimal)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
== Wish list ==
+
For a lists of ideas on how to contribute, please see [[Get_involved|Get involved]].
  
−
=== Containers ===
+
''' This page is superseded by [https://github.com/dlang/projects projects]'''
−
No one is working on this. It's tough to get started because, despite lots of discussion at various times on this forum, no one seems to really know what they want. Since the containers in question are well-known, it's much more a design problem than an implementation problem.
 
  
−
'''Update''': there has been a lot of progress made towards GC-free containers with [https://github.com/economicmodeling/containers EMSI Containers].
+
== Easy tasks ==
  
−
=== Compression/archiving ===
+
== Walter and Andrei's Action List ==
−
Opening standard compressed/archived file formats needs to just work. This includes at least zip, gzip, tar and bzip2. Of course, zip already is available and gzip is supported by the zlib module but with a crufty C API. At least gzip and bzip2, which are stream-based as opposed to file-based, should be handled via streams, which means that streams block compression/archiving. Also, since tar and zip are both file based, they should probably be handled by the same API, which might mean deprecating std.zip and rewriting it.
 
  
−
=== Encryption and hashing ===
+
=== Walter's List ===
−
This is more an implementation problem than a design problem. No one is working on it. Some work has been done here but it's unfinished. One of the ideas is to wrap OpenSSL? at first and then implement the most useful crypto primitives in D to avoid library dependency and to make them usable with CTFE.  
+
[https://forum.dlang.org/post/nk49h1$sv8$1@digitalmars.com discussion]
 +
{| class="wikitable"
 +
|-
 +
! Id
 +
! Description
 +
! Guides / People working on
 +
|-
 +
| 1 ||eliminate all gratuitous use of gc
 +
|-
 +
| 2 ||review all Phobos modules for compatibility with ranges - std.zip, for example, was done before ranges and does not work with them
 +
|-
 +
| 3 ||use -cov to improve code coverage of Phobos modules || [https://codecov.io/gh/dlang/phobos/tree/master/std Browse annotated files on Codecov]
 +
|-
 +
| 4 ||make sure every function in Phobos has an example || Reduce the <code>has_public_example</code> module blacklist in <code>.dscanner.ini</code>
 +
|-
 +
| 5 || make sure every function in Phobos has Params: and Returns: sections http://www.digitalmars.com/d/archives/digitalmars/D/Phobos_Documentation_-_call_to_action_258777.html || Reduce the <code>properly_documented_public_functions</code> module blacklist in <code>.dscanner.ini</code>
 +
|-
 +
| 6 || replace std.xml with something we can be proud of || https://github.com/lodo1995/experimental.xml
 +
|-
 +
| 7 || compile a list of popular modules in other languages and see what we should have
 +
|-
 +
| 8 || create a greenthreads module that works like Goroutines
 +
|-
 +
| 9 || create a module that enables code to be run on GPUs || [https://github.com/thewilsonator/ldc/tree/dcompute dcompute]
 +
|-
 +
| 10 || now that D can interface to C++ templates and exceptions, create the interface code to the C++ STL || [http://dconf.org/2017/talks/caciulescu.html Alexandru Razvan Caciulescu]
 +
|-
 +
| 11 || review all of Phobos for @safe compatibility || [http://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d Guide to <code>@trusted</code>]
 +
|-
 +
| 12 || remove dependency on autodecode from Phobos || [https://github.com/dlang/phobos/pull/5513 see PR #5513 for a start]
 +
|-
 +
| 13 || there was recently a thread on Phobos desperately needing a BigDecimal module, someone helpfully posted links to a couple of free C versions, I suggested that someone build a D wrapper for one or convert one to D. Sadly, that was the end of the discussion
 +
|-
 +
| 14 || I regularly ask people to write articles about D, and the situation is slowly getting better, in that more and more good ones are getting written
 +
|-
 +
|}
  
−
=== An improved std.json ===
+
=== Andrei's List ===
−
Nobody is working on this right now. [[Wish_list/std.json]] documents the issues with the current std.json and some requirements for a replacement.
 
−
'''Update:''' See [https://github.com/s-ludwig/std_data_json std.data.json] for recent development.
 
  
−
=== An improved std.xml ===
+
{| class="wikitable"
−
Maybe Thomas Sowinski is working on a replacement, but haven't seen any updates in a long time. There was also [https://launchpad.net/d2-xml xml2] which was abandoned too.
+
|-
 +
! Id
 +
! Description
 +
! People working on
 +
|-
 +
| ? || Complete implementation of @safe
 +
| Discussion at: https://forum.dlang.org/post/auowltizusrdhzjbimlg@forum.dlang.org
 +
|}
  
−
'''Update:''' Lodovico Giaretta is working on this as part of this GSoC project - [https://github.com/lodo1995/experimental.xml WiP code]
+
== Wish list for new modules ==
  
−
=== Matrices and linear algebra ===
+
Walter and Andrei have veto rights when it comes to inclusion of new stuff into DMD, druntime, and phobos.
−
[https://github.com/cristicbz/scid Cristi Cobzarenco's GSoC? project] is a good starting point but it needs polish. He has indicated that he wants to get back to working on it but doesn't have time.
+
So if you're looking to work on new stuff either pick something from the list. Or get in contact with Walter or Andrei early during the design phase of your project.
−
 
+
This way you can avoid a lot of frustration.
−
'''Update:''' Matrices are now merged part of Phobos (std.experimental.ndslice) and Ilya Yaroshenko started a new project - [https://github.com/DlangScience/mir mir] which will cover more numeric functionalities.
 
−
 
 
−
=== std.database ===
 
−
This is a large, complicated project because we're trying to define a common API for a variety of RDBMSs. Again, it's more a design problem than an implementation problem. There is at least one current attempt at a unified interface: [https://github.com/buggins/ddbc DDBC]
 
−
(See also: [Database_Libraries]).
 
  
−
=== Parallel algorithms ===
+
=== Containers (WIP) ===  
−
dsimcha has implemented a decent amount of these in his std.parallel_algorithm Github project, but has become somewhat frustrated and unmotivated to finish this project because so many of the relevant algorithms seem memory bandwidth bound and aren't substantially faster when parallelized than when run serially.
 
  
−
=== Native curl replacement ===
+
No one is working on this. It's tough to get started because, despite lots of discussion at various times on this forum, no one seems to really know what they want. Since the containers in question are well-known, it's much more a design problem than an implementation problem. There has been a lot of progress made towards GC-free containers with [https://github.com/economicmodeling/containers EMSI Containers] and Eduard Staniloiu is working on  [http://dconf.org/2017/talks/staniloiu.html a new collections framework].
−
[http://dlang.org/phobos/std_net_curl.html std.net.curl] is a wrapper around the low-level bindings to the C library curl which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending std.net.curl is quite hard. A [https://github.com/ikod/dlang-requests/issues/10 replacement library] is already WiP, but still needs help and tester to get ready for primetime.
 
  
−
=== Native SQLite replacement ===
+
=== An improved std.json (WIP) ===
−
[http://dlang.org/phobos/etc_c_sqlite3.html etc.c.sqlite3] is a wrapper around the low-level bindings to the C library SQLite3 which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending this library is quite hard.
+
Nobody is working on this right now. [[Wish_list/std.json]] documents the issues with the current std.json and some requirements for a replacement.
−
There's already a [https://github.com/UplinkCoder/sqlite-d SQLite Reader] in alpha that takes CTFE optimizations into account, but of-course write access needs to be provided too.
+
'''Update:''' See [https://github.com/s-ludwig/std_data_json std.data.json] for recent development.
  
−
=== Native ZLib replacement ===
+
=== Native curl replacement (WIP) ===
−
 
+
[http://dlang.org/phobos/std_net_curl.html std.net.curl] is a wrapper around the low-level bindings to the C library curl which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending std.net.curl is quite hard. A [https://github.com/ikod/dlang-requests replacement library] is already WiP, but still needs help and tester to get ready for primetime.
−
[http://dlang.org/phobos/etc_c_zlib.html etc.c.zlib] is a wrapper around the low-level bindings to the C library Zlib which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending this library is quite hard.
 
−
The best existing library is [https://github.com/rcythr/archive archive].
 
  
 
=== Better IO with ranges ===
 
=== Better IO with ranges ===
Line 49: Line 78:
 
Ideally `std.stdio` should have a better range support. So far  
 
Ideally `std.stdio` should have a better range support. So far  
 
[https://github.com/jasonwhite/io io], [https://github.com/schveiguy/iopipe iopipe] and [https://github.com/rejectedsoftware/vibe.d/blob/master/stream/vibe/stream/stdio.d Vibe.d's streaming interface] emerged, but haven't got sufficient testing.
 
[https://github.com/jasonwhite/io io], [https://github.com/schveiguy/iopipe iopipe] and [https://github.com/rejectedsoftware/vibe.d/blob/master/stream/vibe/stream/stdio.d Vibe.d's streaming interface] emerged, but haven't got sufficient testing.
−
`std.io` is reserved for the new io module.
+
`std.io` is reserved for the new io module. See also the [http://dconf.org/2017/talks/schveighoffer.html DConf17 talk about iopipe].
 +
 
  
−
=== Eventloop ===
+
=== Eventloop (WIP) ===
  
 
Event loops have three common types.
 
Event loops have three common types.
Line 70: Line 100:
 
Threading is also usually included with sockets for the usage by multithreaded web servers. A D (and in Phobos) implementation should take this into consideration with support of non-D event loops.
 
Threading is also usually included with sockets for the usage by multithreaded web servers. A D (and in Phobos) implementation should take this into consideration with support of non-D event loops.
  
−
At the moment D's flagship web framework [https://github.com/rejectedsoftware/vibe.d Vibe.d] depends upon libevent - a C eventloop library. Installing this library often creates troubles as well as optimizing it. D should have a proper cross-platform event loop library with multithreading support that can be used as a general-purpose asynchronous library. [https://github.com/etcimon/libasync Libasync] is work in progress, however more testers and help is needed to make it a rock-solid library.
+
At the moment D's flagship web framework [https://github.com/rejectedsoftware/vibe.d Vibe.d] has an eventloop abstraction as [https://github.com/vibe-d/eventcore eventcore].
 +
However, by default [https://github.com/vibe-d/eventcore eventcore] uses libevent - a C eventloop library. Installing this library often creates troubles as well as optimizing it.
 +
D should have a proper cross-platform event loop library with multithreading support that can be used as a general-purpose asynchronous library.
 +
[https://github.com/etcimon/libasync Libasync] is work in progress, however more testers and help is needed to make it a rock-solid library.
 +
 
 +
 
 +
=== Compression/archiving ===
 +
Opening standard compressed/archived file formats needs to just work. This includes at least zip, gzip, tar and bzip2. Of course, zip already is available and gzip is supported by the zlib module but with a crufty C API. At least gzip and bzip2, which are stream-based as opposed to file-based, should be handled via streams, which means that streams block compression/archiving. Also, since tar and zip are both file based, they should probably be handled by the same API, which might mean deprecating std.zip and rewriting it.
 +
 
 +
=== Encryption and hashing ===
 +
This is more an implementation problem than a design problem. No one is working on it. Some work has been done here but it's unfinished. One of the ideas is to wrap OpenSSL? at first and then implement the most useful crypto primitives in D to avoid library dependency and to make them usable with CTFE.
 +
 
 +
=== An improved std.xml ===
 +
 
 +
Lodovico Giaretta was working on this as part of this [https://github.com/lodo1995/experimental.xml GSoC project], but his [https://github.com/dlang/phobos/pull/4741 Phobos PR] was abandoned.
 +
 
 +
=== std.database ===
 +
This is a large, complicated project because we're trying to define a common API for a variety of RDBMSs. Again, it's more a design problem than an implementation problem. There is at least one current attempt at a unified interface: [https://github.com/buggins/ddbc DDBC]
 +
(See also: [[Database_Libraries|Database libraries]] or Erik Smith's DConf16 talk about [http://dconf.org/2016/talks/smith.html A D standard database interface and implementation]).
 +
 
 +
=== Parallel algorithms ===
 +
dsimcha has implemented a decent amount of these in his [https://github.com/dsimcha/parallel_algorithm std.parallel_algorithm] Github project, but has become somewhat frustrated and unmotivated to finish this project because so many of the relevant algorithms seem memory bandwidth bound and aren't substantially faster when parallelized than when run serially.
 +
 
 +
=== Native SQLite replacement ===
 +
[http://dlang.org/phobos/etc_c_sqlite3.html etc.c.sqlite3] is a wrapper around the low-level bindings to the C library SQLite3 which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending this library is quite hard.
 +
There's already a [https://github.com/UplinkCoder/sqlite-d SQLite Reader] in alpha that takes CTFE optimizations into account, but of-course write access needs to be provided too.
 +
 
 +
=== Native ZLib replacement ===
 +
 
 +
[http://dlang.org/phobos/etc_c_zlib.html etc.c.zlib] is a wrapper around the low-level bindings to the C library Zlib which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending this library is quite hard.
 +
The best existing library is [https://github.com/rcythr/archive archive].
  
 
=== std.encoding ===
 
=== std.encoding ===
Line 82: Line 142:
  
 
A general decimal math library for fixed point arithmetics.
 
A general decimal math library for fixed point arithmetics.
−
Existing libraries are [https://github.com/andersonpd/eris/ eris] and [https://github.com/jaypha/fixed fixed].
+
Existing libraries are [https://github.com/andersonpd/eris/ eris], [https://github.com/jaypha/fixed fixed] and [https://github.com/m3m0ry/fixedpoint fixedpoint].
  
−
=== Other questionable modules ===
+
=== Existing modules which have been extended ===
  
−
This list is a brief overview of developed replacements in the community.
+
This list is a brief overview of developed replacements by the community.
 
It is intended to show which modules might deserve a bit more attendance:
 
It is intended to show which modules might deserve a bit more attendance:
−
 
  
 
* std.base64
 
* std.base64
Line 94: Line 153:
 
** https://github.com/e10s/d-base32 (base32)
 
** https://github.com/e10s/d-base32 (base32)
 
* std.bigint vs. [https://github.com/andersonpd/eris/blob/master/integer/extended.d extended]
 
* std.bigint vs. [https://github.com/andersonpd/eris/blob/master/integer/extended.d extended]
−
* std.csv vs. [https://github.com/eBay/tsv-utils-dlang tsv-utils] (in general a CSV module should have a [pandas.pydata.org/pandas-docs/stable/10min.html Pandas]-like API with full range support
+
* std.csv vs. [https://github.com/eBay/tsv-utils-dlang tsv-utils] (in general a CSV module should have a [http://pandas.pydata.org/pandas-docs/stable/10min.html Pandas]-like API with full range support
 
* std.getopt - there are many community solutions:
 
* std.getopt - there are many community solutions:
−
** https://github.com/jasonwhite/darg
+
** [https://github.com/jasonwhite/darg darg]
−
** https://github.com/SirTony/commando
+
** [https://github.com/SirTony/commando Commando]
 +
** [https://blog.thecybershadow.net/2014/08/05/ae-utils-funopt FunOpt]
 
* std.math vs. [https://github.com/libmir/mir-math mir-math] and [https://code.dlang.org/packages/ctstdmath ctstdmath]
 
* std.math vs. [https://github.com/libmir/mir-math mir-math] and [https://code.dlang.org/packages/ctstdmath ctstdmath]
−
* std.net.isemail vs [https://github.com/anton-dutov/mail mail] and [http://vibed.org/api/vibe.mail.smtp/Mail vibe.mail.smtp]
 
 
* std.signals vs. [https://code.dlang.org/packages/phobosx PhobosX.signals], [https://code.dlang.org/packages/observe observe]
 
* std.signals vs. [https://code.dlang.org/packages/phobosx PhobosX.signals], [https://code.dlang.org/packages/observe observe]
−
* std.socket vs. [http://vibed.org/api/vibe.http.websockets Vibe's sockets
+
* std.socket vs. [http://vibed.org/api/vibe.http.websockets Vibe's sockets]
 
* std.uri vs [https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/uri.d alphaPhobos], [http://vibed.org/api/vibe.inet.url/ vibe.inet.url], [https://github.com/adamdruppe/arsd/blob/master/http2.d arsd]
 
* std.uri vs [https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/uri.d alphaPhobos], [http://vibed.org/api/vibe.inet.url/ vibe.inet.url], [https://github.com/adamdruppe/arsd/blob/master/http2.d arsd]
 
* std.variant vs.[https://github.com/s-ludwig/taggedalgebraic taggedalgebraic]
 
* std.variant vs.[https://github.com/s-ludwig/taggedalgebraic taggedalgebraic]
  
−
== Walter and Andrei's Action List ==
 
−
 
−
Walter and Andrei have veto rights when it comes to inclusion of new stuff into DMD, druntime, and phobos.
 
−
So if you're looking to work on new stuff either pick something from the list. Or get in contact with Walter or Andrei early during the design phase of your project.
 
−
This way you can avoid a lot of frustration.
 
−
 
−
=== Walter's List ===
 
−
[https://forum.dlang.org/post/nk49h1$sv8$1@digitalmars.com discussion]
 
−
{| class="wikitable"
 
−
|-
 
−
! Id
 
−
! Description
 
−
! People working on
 
−
|-
 
−
| 1 ||eliminate all gratuitous use of gc
 
−
|-
 
−
| 2 ||review all Phobos modules for compatibility with ranges - std.zip, for example, was done before ranges and does not work with them
 
−
|-
 
−
| 3 ||use -cov to improve code coverage of Phobos modules || [https://codecov.io/gh/dlang/phobos Browse annotated files on Codecov]
 
−
|-
 
−
| 4 ||make sure every function in Phobos has an example
 
−
|-
 
−
| 5 || make sure every function in Phobos has Params: and Returns: sections http://www.digitalmars.com/d/archives/digitalmars/D/Phobos_Documentation_-_call_to_action_258777.html
 
−
|-
 
−
| 6 || replace std.xml with something we can be proud of || https://github.com/lodo1995/experimental.xml
 
−
|-
 
−
| 7 || compile a list of popular modules in other languages and see what we should have
 
−
|-
 
−
| 8 || create a greenthreads module that works like Goroutines
 
−
|-
 
−
| 9 || create a module that enables code to be run on GPUs || https://github.com/thewilsonator/ldc/tree/dcompute
 
−
|-
 
−
| 10 || now that D can interface to C++ templates and exceptions, create the interface code to the C++ STL
 
−
|-
 
−
| 11 || review all of Phobos for @safe compatibility
 
−
|-
 
−
| 12 || remove dependency on autodecode from Phobos
 
−
|-
 
−
| 13 || there was recently a thread on Phobos desperately needing a BigDecimal module, someone helpfully posted links to a couple of free C versions, I suggested that someone build a D wrapper for one or convert one to D. Sadly, that was the end of the discussion
 
−
|-
 
−
| 14 || I regularly ask people to write articles about D, and the situation is slowly getting better, in that more and more good ones are getting written
 
−
|-
 
−
|}
 
−
 
−
=== Andrei's List ===
 
−
 
−
{| class="wikitable"
 
−
|-
 
−
! Id
 
−
! Description
 
−
! People working on
 
−
|-
 
−
| ? || Complete implementation of @safe
 
−
| Discussion at: https://forum.dlang.org/post/auowltizusrdhzjbimlg@forum.dlang.org
 
−
|}
 
  
 
[[Category:Library Development]]
 
[[Category:Library Development]]

Latest revision as of 09:24, 1 May 2020

For a lists of ideas on how to contribute, please see Get involved.

This page is superseded by projects

Easy tasks

Walter and Andrei's Action List

Walter's List

discussion

Id Description Guides / People working on
1 eliminate all gratuitous use of gc
2 review all Phobos modules for compatibility with ranges - std.zip, for example, was done before ranges and does not work with them
3 use -cov to improve code coverage of Phobos modules Browse annotated files on Codecov
4 make sure every function in Phobos has an example Reduce the has_public_example module blacklist in .dscanner.ini
5 make sure every function in Phobos has Params: and Returns: sections http://www.digitalmars.com/d/archives/digitalmars/D/Phobos_Documentation_-_call_to_action_258777.html Reduce the properly_documented_public_functions module blacklist in .dscanner.ini
6 replace std.xml with something we can be proud of https://github.com/lodo1995/experimental.xml
7 compile a list of popular modules in other languages and see what we should have
8 create a greenthreads module that works like Goroutines
9 create a module that enables code to be run on GPUs dcompute
10 now that D can interface to C++ templates and exceptions, create the interface code to the C++ STL Alexandru Razvan Caciulescu
11 review all of Phobos for @safe compatibility Guide to @trusted
12 remove dependency on autodecode from Phobos see PR #5513 for a start
13 there was recently a thread on Phobos desperately needing a BigDecimal module, someone helpfully posted links to a couple of free C versions, I suggested that someone build a D wrapper for one or convert one to D. Sadly, that was the end of the discussion
14 I regularly ask people to write articles about D, and the situation is slowly getting better, in that more and more good ones are getting written

Andrei's List

Id Description People working on
? Complete implementation of @safe Discussion at: https://forum.dlang.org/post/auowltizusrdhzjbimlg@forum.dlang.org

Wish list for new modules

Walter and Andrei have veto rights when it comes to inclusion of new stuff into DMD, druntime, and phobos. So if you're looking to work on new stuff either pick something from the list. Or get in contact with Walter or Andrei early during the design phase of your project. This way you can avoid a lot of frustration.

Containers (WIP)

No one is working on this. It's tough to get started because, despite lots of discussion at various times on this forum, no one seems to really know what they want. Since the containers in question are well-known, it's much more a design problem than an implementation problem. There has been a lot of progress made towards GC-free containers with EMSI Containers and Eduard Staniloiu is working on a new collections framework.

An improved std.json (WIP)

Nobody is working on this right now. Wish_list/std.json documents the issues with the current std.json and some requirements for a replacement. Update: See std.data.json for recent development.

Native curl replacement (WIP)

std.net.curl is a wrapper around the low-level bindings to the C library curl which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending std.net.curl is quite hard. A replacement library is already WiP, but still needs help and tester to get ready for primetime.

Better IO with ranges

Ideally `std.stdio` should have a better range support. So far io, iopipe and Vibe.d's streaming interface emerged, but haven't got sufficient testing. `std.io` is reserved for the new io module. See also the DConf17 talk about iopipe.


Eventloop (WIP)

Event loops have three common types.

1. Audio

A real time loop to play music (usually only concerned with one thread).

2. Windowing

Per thread event loop that must take input from the OS and move events to the appropriate handler. May utilise multiple system event loops per instance, such as X11 and Wayland.

3. Sockets

Per application event loop that takes ownership of events and messaging to threads.

Threading is also usually included with sockets for the usage by multithreaded web servers. A D (and in Phobos) implementation should take this into consideration with support of non-D event loops.

At the moment D's flagship web framework Vibe.d has an eventloop abstraction as eventcore. However, by default eventcore uses libevent - a C eventloop library. Installing this library often creates troubles as well as optimizing it. D should have a proper cross-platform event loop library with multithreading support that can be used as a general-purpose asynchronous library. Libasync is work in progress, however more testers and help is needed to make it a rock-solid library.


Compression/archiving

Opening standard compressed/archived file formats needs to just work. This includes at least zip, gzip, tar and bzip2. Of course, zip already is available and gzip is supported by the zlib module but with a crufty C API. At least gzip and bzip2, which are stream-based as opposed to file-based, should be handled via streams, which means that streams block compression/archiving. Also, since tar and zip are both file based, they should probably be handled by the same API, which might mean deprecating std.zip and rewriting it.

Encryption and hashing

This is more an implementation problem than a design problem. No one is working on it. Some work has been done here but it's unfinished. One of the ideas is to wrap OpenSSL? at first and then implement the most useful crypto primitives in D to avoid library dependency and to make them usable with CTFE.

An improved std.xml

Lodovico Giaretta was working on this as part of this GSoC project, but his Phobos PR was abandoned.

std.database

This is a large, complicated project because we're trying to define a common API for a variety of RDBMSs. Again, it's more a design problem than an implementation problem. There is at least one current attempt at a unified interface: DDBC (See also: Database libraries or Erik Smith's DConf16 talk about A D standard database interface and implementation).

Parallel algorithms

dsimcha has implemented a decent amount of these in his std.parallel_algorithm Github project, but has become somewhat frustrated and unmotivated to finish this project because so many of the relevant algorithms seem memory bandwidth bound and aren't substantially faster when parallelized than when run serially.

Native SQLite replacement

etc.c.sqlite3 is a wrapper around the low-level bindings to the C library SQLite3 which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending this library is quite hard. There's already a SQLite Reader in alpha that takes CTFE optimizations into account, but of-course write access needs to be provided too.

Native ZLib replacement

etc.c.zlib is a wrapper around the low-level bindings to the C library Zlib which has to be included in the D release. Apart from the licensing issues, it also means that maintaining and extending this library is quite hard. The best existing library is archive.

std.encoding

std.encoding needs a complete overhaul. Other encoding packages as ascii, base64, utf8 could be included and a common API should unite them.

This new package could include a comprehensive set of encoder, covering (in addition to base64 and utf8) all the baseXX encoders, since they are easy addition (base16, base32, z85) and also domain specific encoders such as percent encoding (which then could be used in any replacement of the old-fashioned and incomplete std.uri module) or variable length quantity. Obviously the final list of encoders should be discussed on the NG.

std.decimal

A general decimal math library for fixed point arithmetics. Existing libraries are eris, fixed and fixedpoint.

Existing modules which have been extended

This list is a brief overview of developed replacements by the community. It is intended to show which modules might deserve a bit more attendance:

Retrieved from "https://wiki.dlang.org/?title=Wish_list&oldid=9788"