berni44 dlang at
Tue Jan 7 12:44:40 UTC 2020

On Tuesday, 7 January 2020 at 01:10:08 UTC, Jonathan M Davis 
> Are you talking about putting them all in a single module or 
> all in a single package?

Sorry, for being unclear here. I thought of a package.

> Now, personally, I don't think that anything regarding file 
> formats should have been in the standard library in the first 
> place.

Thinking about this whole stuff, I noticed, that there are two 
different points of view, which should be separated: The idealist 
view and the pragmatic view. IMHO both are important.

So when I got you right, from an idealists view, you'd say these 
file formats should be removed from phobos, but from a 
pragmatists view this looks much more difficult.

I think, I share this point of view. But I'd like to get rid of 
them anyway.

> For the most part, I don't see any point in removing any of 
> these modules, since that would break existing code,

Well, every module, that is kept inside Phobos produces (lots of) 
maintainance work. From my perspective, we are missing resources 
here. So I prefere a controlled breaking of code (with 
deprecation and all) instead of having the code rosting and 
breaking uncontrolled sooner or later.

I came up with this issue, when I looked at my own comment on 
issue 17709 [1]: I found the reason for this issue and I think I 
could fix that in a reasonable amout of time. But is it worth it 
doing so if that module might be removed or replaced in the near 
future? Wouldn't it be much better to use that time to fix a bug 
at a more important place?

But on the other side: How does such a comment look like to 
someone how is using std.xml and found that issue, cause he 
stumbled over the same problem? Wouldn't it be better to remove 
std.xml completely in the first place?


And than, there is something more to be thought of: The (public) 
perception of Phobos. If it contains parts, that are more or less 
broken, useless or outdated, this will be the parts where people 
will look at, when they judge. It won't help much to have other 
parts, that work well.

> BTW, base64 isn't really a file format. It's an encoding.

Really? So why isn't it in std.encoding? :-) I know, that base64 
is somewhat different, maybe it's in the gray area... Or look at 
it the other way round: Isn't zipping also just encoding and 
unzipping decoding?

More information about the Digitalmars-d mailing list