In the 2015H1 vision document[1] it states the following:

<quote>
*Foster additions to the standard library and third-party libraries*
We prefer adding new components to the standard library over refactorings and reorganizations of those that work (barring bug fixes). Our vision is to foster a large standard library complemented by a strong battery of third-party libraries. Aspects like networking, concurrent/parallel/distributed programming, and database connectivity are of interest to place in the standard library.
</quote>

1. Are you wanting a large "batteries included" standard library a'la Python[2] or only focused around the aspects mentioned?

2. When implementing something like 'std.database' do you see this as bindings to libraries (similar to std.net.curl[3]) or an implementation of the relevant specification/protocols etc. to negate the need for dependencies?

3. When mentioning networking, do you mean email handling, http servers, sockets etc? Do you see this replacing std.net.curl?

[1]: http://wiki.dlang.org/Vision/2015H1
[2]: https://docs.python.org/3.4/library/
[3]: http://dlang.org/phobos/std_net_curl.html

On 4/5/15 10:48 AM, Gary Willoughby wrote:
> In the 2015H1 vision document[1] it states the following:
>
> <quote>
> *Foster additions to the standard library and third-party libraries*
> We prefer adding new components to the standard library over
> refactorings and reorganizations of those that work (barring bug fixes).
> Our vision is to foster a large standard library complemented by a
> strong battery of third-party libraries. Aspects like networking,
> concurrent/parallel/distributed programming, and database connectivity
> are of interest to place in the standard library.
> </quote>
>
> 1. Are you wanting a large "batteries included" standard library a'la
> Python[2] or only focused around the aspects mentioned?

Batteries included.

> 2. When implementing something like 'std.database' do you see this as
> bindings to libraries (similar to std.net.curl[3]) or an implementation
> of the relevant specification/protocols etc. to negate the need for
> dependencies?

Universal. I think ODBC is the best option here.

> 3. When mentioning networking, do you mean email handling, http servers,
> sockets etc? Do you see this replacing std.net.curl?

All of the above. Some may build on curl, some may complement it, some may replace some of its functionality.


Andrei

Andrei Alexandrescu:

>> 1. Are you wanting a large "batteries included" standard library a'la
>> Python[2] or only focused around the aspects mentioned?
>
> Batteries included.

This is a quite significant decision. It has both advantages and disadvantages. (I think Rust has chosen to have a lighter std lib).

Bye,
bearophile

On 4/5/15 12:02 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>>> 1. Are you wanting a large "batteries included" standard library a'la
>>> Python[2] or only focused around the aspects mentioned?
>>
>> Batteries included.
>
> This is a quite significant decision. It has both advantages and
> disadvantages. (I think Rust has chosen to have a lighter std lib).

No doubt we must go with a large stdlib. Virtually all but a couple languages are experiencing significant growth in stdlib. -- Andrei

On 6/04/2015 6:31 a.m., Andrei Alexandrescu wrote:
> On 4/5/15 10:48 AM, Gary Willoughby wrote:
>> In the 2015H1 vision document[1] it states the following:
>>
>> <quote>
>> *Foster additions to the standard library and third-party libraries*
>> We prefer adding new components to the standard library over
>> refactorings and reorganizations of those that work (barring bug fixes).
>> Our vision is to foster a large standard library complemented by a
>> strong battery of third-party libraries. Aspects like networking,
>> concurrent/parallel/distributed programming, and database connectivity
>> are of interest to place in the standard library.
>> </quote>
>>
>> 1. Are you wanting a large "batteries included" standard library a'la
>> Python[2] or only focused around the aspects mentioned?
>
> Batteries included.
>
>> 2. When implementing something like 'std.database' do you see this as
>> bindings to libraries (similar to std.net.curl[3]) or an implementation
>> of the relevant specification/protocols etc. to negate the need for
>> dependencies?
>
> Universal. I think ODBC is the best option here.
>
>> 3. When mentioning networking, do you mean email handling, http servers,
>> sockets etc? Do you see this replacing std.net.curl?
>
> All of the above. Some may build on curl, some may complement it, some
> may replace some of its functionality.
>
>
> Andrei

On that note, anyone willing to help create and ODBC host via Derelict or will I be doing something like that?

Andrei, if vibed will include in DMD distribution, would it's mean that common libs (like json) will be merged with DMD? I think it would very rational step.

On Monday, 6 April 2015 at 03:19:03 UTC, Rikki Cattermole wrote:
> On that note, anyone willing to help create and ODBC host via Derelict or will I be doing something like that?

I don't understand this sentence. :/

On 4/7/15 10:22 AM, Suliman wrote:
> Andrei, if vibed will include in DMD distribution, would it's mean that
> common libs (like json) will be merged with DMD? I think it would very
> rational step.

You mean in std? Some if not all, but each needs to pass review. -- Andrei

>> 3. When mentioning networking, do you mean email handling, http servers,
>> sockets etc? Do you see this replacing std.net.curl?
>
> All of the above. Some may build on curl, some may complement it, some may replace some of its functionality.

I would like to see e.g. libasync mature a bit and get into std.async. From there http, ftp... client and server could be added to std.net if we want to.

I am currently using libasync in Deadcode with great success.

https://github.com/etcimon/libasync

/Jonas

On Sunday, 5 April 2015 at 18:31:37 UTC, Andrei Alexandrescu
wrote:
> On 4/5/15 10:48 AM, Gary Willoughby wrote:
> Universal. I think ODBC is the best option here.

Maybe it is for std.database.sql or std.database.relational


Andrea