On Friday, 24 May 2013 at 03:19:48 UTC, Marco Leise wrote:
> Am Tue, 21 May 2013 20:34:02 +0200
> schrieb Jacob Carlborg <doob@me.com>:
>
>> On 2013-05-21 19:53, Idan Arye wrote:
>> 
>> > The problem is that people that need Unicode stuff see `std.utf` and
>> > assume that all Unicode related stuff are there.
>> 
>> I never can remember if I should look in std.utf or std.uni. That wouldn't change if it was renamed to std.unicode.
>
> ...and looking at the content I really wonder what the
> distinction is. I wouldn't say that "Unicode" is much more
> than "Utf". All in all it is another way (or several ways) to
> assign numbers to characters. Before this long discussion I
> thought "std.encoding.unicode", "std.encoding.ascii", etc.
> makes sense and I still think so. It also makes it more
> likely that authors of such modules try to keep a common
> layout or set of functions for everything in std.encoding.
> Just my 2¢ ;)

To make it precise, unicode is a association between characters and numbers. An encoding is how theses number actually are stored in a file. Typical encoding for unicode are utf-8/16/32

On Thursday, 23 May 2013 at 08:49:15 UTC, Jonathan M Davis wrote:
> I tried to fix all of the naming problems in Phobos previously with the idea
> that we'd fix them all and then move on, and I got a large portion of them
> fixed, but I didn't get them all, and I think that it's past the time when it's
> reasonable to do so. There are too many people pushing for stability, and the
> lack of perceived stability is one of D's biggest detractors right now
> (regardless of what our actual level of stability is). Walter and Andrei in
> particular are of the opinion that the ROI on name changes at this point is
> too low for it to be worth it. Sure, aesthetically, it would be nice to fix
> them all, but at some point, we have to just move on and live with what we
> have. Fortunately, _most_ of it has been fixed already, and the biggest
> remaining offenders are modules that should probably be replaced wholesale
> anyway (e.g. std.socket), so they may get fixed if the ROI for replacing such
> modules is high enough (in which case, the fixing of names is a bonus which
> comes along with fixing something which actually _does_ have a ROI for changing
> it).
>

I though more about this. I do think the ROI is very real, but the one that gain the benefit are the one that aren't used to the module. Which mean that the one that will pay for the change won't be the one benefiting from it.

I do think that we have a lot of people to come in the future, and so that the change is worth it. Obviously, who's paying is an issue, and I'd rather work on making that smooth for who's paying than discarding the change altogether.