January 11, 2020
On Friday, January 10, 2020 7:59:23 AM MST berni44 via Digitalmars-d wrote:
> Please vote: should std.xml be deprecated and moved to undeaD?
>
> See https://forum.dlang.org/thread/fnbsikficjsubxrukkae@forum.dlang.org for some lately discussion about this.

Yes.

- Jonathan M Davis



January 11, 2020
On Friday, 10 January 2020 at 14:59:23 UTC, berni44 wrote:
> Please vote: should std.xml be deprecated and moved to undeaD?
>
> See https://forum.dlang.org/thread/fnbsikficjsubxrukkae@forum.dlang.org for some lately discussion about this.


Yes, please.
January 11, 2020
On Friday, 10 January 2020 at 14:59:23 UTC, berni44 wrote:
> Please vote: should std.xml be deprecated and moved to undeaD?
>
> See https://forum.dlang.org/thread/fnbsikficjsubxrukkae@forum.dlang.org for some lately discussion about this.

I don't really agree, what improvement will deprecation bring?
Surely the std.xml module is not perfect, but will deprecation really help std?

I believe that removing it will only leave the std without xml, I don't like the idea of ​​moving too many things out of the std.

I would be happy if std.xml were replaced with a new module, I propose this plan:
1) Create a new module for xml and put it in std.experimental.xml
2) Wait for user feedback
3) Deprecate std.xml and informing users that it will be replaced with std.experimental.xml
4) Replace std.xml with std.experimental.xml and put the old module on undeaD

January 11, 2020
On Saturday, 11 January 2020 at 16:44:03 UTC, Ernesto Castellotti wrote:
> I would be happy if std.xml were replaced with a new module, I propose this plan:
> 1) Create a new module for xml and put it in std.experimental.xml
> 2) Wait for user feedback
> 3) Deprecate std.xml and informing users that it will be replaced with std.experimental.xml
> 4) Replace std.xml with std.experimental.xml and put the old module on undeaD

The problem with this is that 1) is a very hard step to accomplish. There is actually std.experimental.xml, but it's not complete enough to merge into std. It's much easier to develop a non-std XML parser, because you can support only part of functionality (read or write XML) and you can ignore rarely used features like entities.

As soon as you try to merge anything into std, new requirements show up. The library needs to play well with ranges, most people would want it to play nicely with @nogc, it would have to support both reading and writing and should support most if not all XML features.
January 12, 2020
On 12/01/2020 5:44 AM, Ernesto Castellotti wrote:
> I would be happy if std.xml were replaced with a new module, I propose this plan:
> 1) Create a new module for xml and put it in std.experimental.xml
> 2) Wait for user feedback
> 3) Deprecate std.xml and informing users that it will be replaced with std.experimental.xml
> 4) Replace std.xml with std.experimental.xml and put the old module on undeaD

That was the plan.

There is problems with having modules marked as "this thing is bad, don't expect it to be around for much longer" and then keeping it around for 10's of years.

It has come up on Reddit even...

It's not a good look and actively discourages people from using D.
January 11, 2020
On Saturday, 11 January 2020 at 17:11:03 UTC, JN wrote:
> On Saturday, 11 January 2020 at 16:44:03 UTC, Ernesto Castellotti wrote:
>> [...]
>
> The problem with this is that 1) is a very hard step to accomplish. There is actually std.experimental.xml, but it's not complete enough to merge into std. It's much easier to develop a non-std XML parser, because you can support only part of functionality (read or write XML) and you can ignore rarely used features like entities.
>
> As soon as you try to merge anything into std, new requirements show up. The library needs to play well with ranges, most people would want it to play nicely with @nogc, it would have to support both reading and writing and should support most if not all XML features.

What you say is certainly true, but how a removal without a replacement can improve the STD?
January 11, 2020
On Saturday, 11 January 2020 at 17:16:00 UTC, Ernesto Castellotti wrote:
> What you say is certainly true, but how a removal without a replacement can improve the STD?

In my oppinion there are several reasons:

a) Maintaining: Currently I've got the feeling, that we have rather too few people who maintain Phobos (and even when I file several bug fixes, I notice that there are also only limited resources on the side of the reviewers...). The number of bugreports has been increasing for years. Every package in the library adds to the amount of maintainance needed. So it would be wise to reduce the ballast.

b) Public perception: If the library contains problematic modules, people might judge that the whole library and with it the whole language is bad.

c) Eventually mobilizing powers: With the removal, the pressure to get a replacement, might increase. The plan to replace it has been there for 10 years now, as I can read, and it wasn't put into effect. If an xml module is really needed, someone might take this removal as a signal to improve one of the existing replacements or write something better, which might eventally make it into Phobos. And if this doesn't happen, it's probably not needed enough.

Having said this, of course a replacement would be fine for me too, but I don't see any yet nor in the near future.
January 11, 2020
On Friday, 10 January 2020 at 14:59:23 UTC, berni44 wrote:
> Please vote: should std.xml be deprecated and moved to undeaD?
>
> See https://forum.dlang.org/thread/fnbsikficjsubxrukkae@forum.dlang.org for some lately discussion about this.

Has anyone made a write-up detailing what is exactly wrong with std.xml (and maybe certain other Phobos modules too)? I have heard some general complaints about bad APIs and outdated idioms but other than that I am out of the loop.
January 13, 2020
On Saturday, 11 January 2020 at 16:44:03 UTC, Ernesto Castellotti wrote:
> I would be happy if std.xml were replaced with a new module, I propose this plan:
> 1) Create a new module for xml and put it in std.experimental.xml
> 2) Wait for user feedback
> 3) Deprecate std.xml and informing users that it will be replaced with std.experimental.xml
> 4) Replace std.xml with std.experimental.xml and put the old module on undeaD

I am for this option.

I believe that processing XML (as well as JSON etc.) is such a universal task, that it is reasonable to be included in the standard library. In the other case reinventing the wheel will continue and bigger projects may end up having a few different XML implementations in their dependency tree.

The other option could be to bring an existing library on code.dlang.org to Phobos - reach to its author, adapt it to Phobos' style and guidelines and make it the new std.xml. Has such an option been considered?
January 14, 2020
On 13/01/2020 11:39 PM, Piotr Mitana wrote:
> The other option could be to bring an existing library on code.dlang.org to Phobos - reach to its author, adapt it to Phobos' style and guidelines and make it the new std.xml. Has such an option been considered?

Yes.
dxml is the closest and the author isn't keen to go down that right now.