On Tuesday, May 21, 2013 16:51:01 Dmitry Olshansky wrote:
> The pitch by deadalnix:
> 
> I strongly push into renaming it to std.unicode . As said in the other thread : uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever.
> 
> When theses pile up in a large library, this is more and more difficult to rely on intuition/autocompletion and much more on programmer's memory. It mean that it takes longer to learn the whole library.
> 
> 
> My reservations:
> 
> If the chief benefit of renaming is aesthetics then I'd rather pass. This kind of knee-jerk changes made on basis of "a good time to try to push a better name" just don't belong in design of library/package structure. Yeah, I know nobody is going to say "package structure" looking at Phobos.
> 
> If we make it a part of restructuring std.* that is long overdue then I'm fine as long as package structure is well thought out as a whole. Changing it now before adopting a package structure risks the 2nd change and another set of arguments for keeping things as is.
> 
> Let's continue discussion here and not in voting thread.

I'm completely against renaming it. It will break code for little benefit. And given that std.uni is actually one of the modules that you're _likely_ to have to give the full path to (in particular because std.ascii has many of the same functions but for ASCII), making it longer would be annoying. Maybe std.unicode would be okay if we were creating a brand new module, but std.uni already exists. Let's just leave it as-is.

- Jonathan M Davis

On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote:

> I see people have no idea what Unicode is about.
> Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding.

Point taken. Nevertheless, it's all still all rather confusing (and I even know the difference between encodings and unicode and I still conflated them).

On Tuesday, 21 May 2013 at 19:40:03 UTC, eles wrote:
> On Tuesday, 21 May 2013 at 18:23:42 UTC, Dmitry Olshansky wrote:
>> 21-May-2013 22:12, Brad Anderson пишет:
>>> On Tuesday, 21 May 2013 at 17:53:02 UTC, Idan Arye wrote:
>> I see people have no idea what Unicode is about.
>> Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding.
>
> Good point, but this fact only supports the assertion that the current state of phobos is even more messy than expected. So, a bit of cleaning is required.
>
> Since we are at it, ascii is both a standard *and* an encoding (well, the only one), so were should be put? in std.encoding.* or in std.standard.*? maybe std.text.ascii? std.text.unicode? std.text.utf?

`std.standard` is a bad name for a package. Sure, ASCII is a standard, but the fact that it is a standard has nothing to do with what the `*.ascii` module does - you won't find a function in `std.ascii` that sends an email to the committee with an improvement suggestion for the next edition.

Ofcourse, one can only claim that the only reason such function does not exist is that the ASCII standard would probably never see another update...

On the other hand, all the functions in `std.ascii` have something much do with the fact that ASCII is an encoding, so `std.encoding.ascii` is a good name.

Same with `*.unicode` - even though it has a better chance than the ASCII version, you see a function to mail a suggestion there either. And yes, it's an algorithm - but almost everything is an algorithm!

Unicode and ASCII, even if you can argue they are not exactly and only encodings, are *about* encoding - and that's why they fit in `std.encoding.*`.

On Tuesday, 21 May 2013 at 20:12:37 UTC, Jonathan M Davis wrote:

> I'm completely against renaming it. It will break code for little benefit. And
> given that std.uni is actually one of the modules that you're _likely_ to have
> to give the full path to (in particular because std.ascii has many of the same
> functions but for ASCII), making it longer would be annoying. Maybe
> std.unicode would be okay if we were creating a brand new module, but std.uni
> already exists. Let's just leave it as-is.
>
> - Jonathan M Davis

Would the public import people are suggesting not work for maintaining backward compatibility?

Also, couldn't you just do import uni = std.unicode to save on typing in modules that make use of both std.ascii and std.unicode (that's even less typing than the current requirement to type the fully qualified name which includes std)?

On Tuesday, 21 May 2013 at 17:31:59 UTC, Andrei Alexandrescu wrote:
> On 5/21/13 1:27 PM, Steven Schveighoffer wrote:
>> Then we can correctly judge whether the name change is worth doing. I
>> don't know that it is. std.uni is not immediately recognizable as
>> something else, so it warrants a lookup in the docs. Yes, less obvious,
>> but not horrifically misnamed. I don't think it's worth the effort to
>> rename at this point unless it's shown that nearly nobody uses it.
>
> I agree. I'd personally love it if std.unicode replaced std.uni, but at this point the rename is insufficiently motivated. It's not like people go, "hmmm I need some Unicode stuff, let me see if std.unicode is there. No? The hell with it, I'm moving to another language."
>
>
> Andrei

It isn't really a rename as a new module is being integrated. We can keep what we have under std.uni for a while. If you want the new hotness, go for std.unicode .

On Tue, 21 May 2013 19:04:25 +0100, Simen Kjaeraas <simen.kjaras@gmail.com> wrote:

> On 2013-05-21, 16:02, Regan Heath wrote:
>
>> On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
>>> 21-May-2013 17:03, Regan Heath пишет:
>>> [snip]
>> [snip]
> [snip]
>>>> Meaning if we can make an incremental change for the better
>>>
>>> For better how? The endless churn in my opinion is not worth the incremental change for better. You also would have to argue for every single change with folks pushing whichever way they feel like to (not talking about uni). This is a proverbial "design by committee".
>>
>> Another generalisation.  No-one is suggesting we start renaming modules just because user X wants to.  All I suggested is that if we get a chance to do so at the same time as another breaking change to the same module, we should - provided the benefit of the rename is clear.
>
> I believe his point was rather that this time around we get std.unicode.
> Next module is std.encoding.ascii, and then comes std.text.ebcdic.
>
> I'm all for calling it *.unicode instead of *.uni - that part is only
> logical. However, there should be a roadmap as to whether * should be
> std, std.encoding, or whatever.

Agreed, we need a goal/structure to work towards.  Given that we can make simple/single changes toward that goal/direction as/when possible.  It's like renovating a house, you do it room by room and never change the colour scheme/design half way through - or you'd have to go back and re-do the first rooms.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 05/21/2013 12:56 PM, Andrei Alexandrescu wrote:
> On 5/21/13 1:53 PM, 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 understand. Well, std.utf's documentation can always cross-reference into std.unicode etc. Basically what I'm saying is that nowadays searching and cross-referencing is fairly commoditized so we needn't worry about people being unable to find things that are there.
> 
> Andrei

What about a tool, similar to "2to3.py" or whatever it's called? It would be nice to start heading in that direction in either case.

I can see minor things like this potentially being fixed automatically, and with a nice warning to let you know to stop doing it.

On Tue, 21 May 2013 19:23:36 +0100, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 21-May-2013 22:12, Brad Anderson пишет:
>> On Tuesday, 21 May 2013 at 17:53:02 UTC, 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 see (and experience myself) a lot of confusion over this. Dealing with
>> strings a person constantly has to guess which of these modules has what
>> they are looking for:
>>
>> std.algorithm
>> std.ascii
>> std.conv
>> std.encoding
>> std.range
>> std.string
>> std.format
>> std.uni
>> std.utf
>>
>> It's a mess. At least grouping the encoding stuff together would give it
>> some structure.
>
> I see people have no idea what Unicode is about.
> Unicode is not only the encoding - it's a de facto standard of internationalization and related algorithms. UTF is encoding.

So.. surely this suggests some structure would help with that, i.e.

std.encoding.ascii
std.encoding.latin1
std.encoding.utf

std.i18n.unicode

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 05/21/2013 12:56 PM, Andrei Alexandrescu wrote:
> On 5/21/13 1:53 PM, 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 understand. Well, std.utf's documentation can always cross-reference into std.unicode etc. Basically what I'm saying is that nowadays searching and cross-referencing is fairly commoditized so we needn't worry about people being unable to find things that are there.
> 
> Andrei

Lol, I see the talk about it on the talk now.

On Tuesday, May 21, 2013 22:32:00 Brad Anderson wrote:
> Would the public import people are suggesting not work for maintaining backward compatibility?
> 
> Also, couldn't you just do import uni = std.unicode to save on typing in modules that make use of both std.ascii and std.unicode (that's even less typing than the current requirement to type the fully qualified name which includes std)?

Of course we can provide a migration path, but you're still talking about breaking code, and I don't think that std.uni is a bad enough name to merit that.

If we were starting from scratch or didn't care about breaking code, then I think that std.unicode would make good sense. std.uni is nice and short, but it's overly short. However, we're _not_ starting from scratch and we do care about breaking code - and we're caring about that more and more. So, I don't think that renaming it at this point would be appropriate.

- Jonathan M Davis