Hi all,

today Johannes and I had a short discussion on Github about std.base64. I think his post is a good summary of the status quo:

> base64 shouldn't be a top level module though, moving it to a new package std.encoding may be a good idea. std.base64 is just quite old and when it was written we didn't use subpackages in phobos yet. std.utf and std.ascii are also encodings and could be moved to std.encoding as well, AFAICS. And we also have a std.encoding module which should be part of the same package.

That being said I know that such housekeeping isn't liked a lot, but with `public import` we can very easily mitigate breakage and allow a long deprecation period.
What's your opinion on this? Any major objections?

Cheers,

Seb

[1] https://github.com/dlang/phobos/pull/4720#issuecomment-238348553

On Monday, 8 August 2016 at 19:42:50 UTC, Seb wrote:
> Hi all,
>
> today Johannes and I had a short discussion on Github about std.base64. I think his post is a good summary of the status quo:
>
>> base64 shouldn't be a top level module though, moving it to a new package std.encoding may be a good idea. std.base64 is just quite old and when it was written we didn't use subpackages in phobos yet. std.utf and std.ascii are also encodings and could be moved to std.encoding as well, AFAICS. And we also have a std.encoding module which should be part of the same package.
>
> That being said I know that such housekeeping isn't liked a lot, but with `public import` we can very easily mitigate breakage and allow a long deprecation period.
> What's your opinion on this? Any major objections?
>
> Cheers,
>
> Seb
>
> [1] https://github.com/dlang/phobos/pull/4720#issuecomment-238348553

They're all related to encoding but they don't have a proper common interface like std.digest or std.experimental.allocators

I think it would be justified for something like

std.encoding.variable_length_quantity
std.encoding.z85
std.encoding.base64
std.encoding.base32
std.encoding.base16
etc...

with an uniform API (decode, encode, + specialized helpers)

I you do it as the modules are now it's gonna look like the content of a girl bag because of no uniform API.

In short I'm against unless a serious work is done on the API, otherwise it's just a crappy useless refactoring.

On Monday, 8 August 2016 at 19:42:50 UTC, Seb wrote:
> ...

Also see https://github.com/dlang/phobos/pull/4599 for more discussion on why std.encoding's current design is problematic, and why it should probably be redesigned.

On Monday, August 08, 2016 19:42:50 Seb via Digitalmars-d wrote:
> Hi all,
>
> today Johannes and I had a short discussion on Github about
>
> std.base64. I think his post is a good summary of the status quo:
> > base64 shouldn't be a top level module though, moving it to a new package std.encoding may be a good idea. std.base64 is just quite old and when it was written we didn't use subpackages in phobos yet. std.utf and std.ascii are also encodings and could be moved to std.encoding as well, AFAICS. And we also have a std.encoding module which should be part of the same package.
>
> That being said I know that such housekeeping isn't liked a lot,
> but with `public import` we can very easily mitigate breakage and
> allow a long deprecation period.
> What's your opinion on this? Any major objections?
>
> Cheers,
>
> Seb
>
> [1] https://github.com/dlang/phobos/pull/4720#issuecomment-238348553

std.encoding needs a complete overhaul. Unfortunately, while I think that that's generally agreed upon, no one has stepped up to do it. So, who knows when it'll be fixed. However, given that std.encoding needs an overhaul, I don't seem much point in moving stuff into it. While it may not be ideal, base64 works where it is, and we can worry about moving it when std.encoding is revamped. If we changed it now and then changed it again when std.encoding got overhauled, then we'd end up breaking code twice just to move a function around.

- Jonathan M Davis

On Tuesday, 9 August 2016 at 00:24:40 UTC, Jonathan M Davis wrote:
> On Monday, August 08, 2016 19:42:50 Seb via Digitalmars-d wrote:
>> [...]
>
> std.encoding needs a complete overhaul. Unfortunately, while I think that that's generally agreed upon, no one has stepped up to do it. So, who knows when it'll be fixed. However, given that std.encoding needs an overhaul, I don't seem much point in moving stuff into it. While it may not be ideal, base64 works where it is, and we can worry about moving it when std.encoding is revamped. If we changed it now and then changed it again when std.encoding got overhauled, then we'd end up breaking code twice just to move a function around.
>
> - Jonathan M Davis

Thanks @ all for your explanations!
FWIW I have added std.encoding to the wiki's wishlist ;-)

https://wiki.dlang.org/Wish_list#std.encoding