On Thursday, 3 August 2017 at 18:04:33 UTC, Suliman wrote:
Moving any third party code to std library have both "pro" and "contra" and it was discussed several times. From my point of view there is nothing wrong with modules outside of std library as long as these modules are visible to newcomers, well documented and have developer support.

HTTP *very* important part in present time. Every modern language should have good native http-lib out of the box. I understand that it's can be done as outside module, but JSON also can be outside, and files can be outside. But I do not think that it's good idea.

http-request is much more friendly and powerful than curl. It's much better to move curl as external package.

I think it shouldn't be included in Phobos *because* it's a good library that we want to see growing.

Let's compare with the case of the original Requests library, in Python. As it is the most downloaded Python library ever there have been discussions about including it in the standard library. After much deliberations Kenneth Reitz (the author) decided that integrating requests in the stdlib would harm it by imposing a slower release cycle not fitting the fast iterations needed by the package. Furthermore so many python programs need requests that most people get to install it one time or another, making it a de facto standard that is standard enough for its purpose. Clearly that decision did not slow Requests development, nor did it hit its popularity. People just do a "pip install requests" and don't care about it anymore.

In D the situation is even easier because it is compiled: the developer is the only one having to add a line to its dub.json, the user doesn't have to care at all. And given that the package still has much room for improvement freezing it in Phobos doesn't strike me as a good idea at all.

Of course Phobos must propose an HTTP interface, but it must propose one that allows you to build better ones, it doesn't have to propose a perfect one (although it would obviously be nice).

Reply via email to