On 2013-05-21 18:11, nazriel wrote:
> Also we have std.algorithm, std.process etc and nobody complains that
> its name is too long.

They had the correct name to begin with. Why std.algorithm or std.process wasn't shortened but std.uni was I have no idea. std.algorithm is a lot newer than the others.

-- 
/Jacob Carlborg

On Tue, 21 May 2013 13:01:57 -0400, nazriel <spam@dzfl.pl> wrote:

> On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer wrote:

>> Deprecated functions don't compile.  Any code that uses it would have to be modified.
>>
>
> They do. Unless you add compiler switch they will compile and only spit out an warning.

So you are right.  That was recently changed in 2.061, I didn't realize that.

-Steve

On Tuesday, 21 May 2013 at 16:52:06 UTC, Steven Schveighoffer wrote:
> On Tue, 21 May 2013 12:43:01 -0400, Regan Heath <regan@netmail.co.nz> wrote:
>
>> On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>>> It has nothing to do with the name.  I think unicode is better.  But (allegedly) we have existing projects that use std.uni, which would break if we renamed.
>>
>> Wouldn't the old std.uni remain but deprecated?
>>
>
> Deprecated functions don't compile.  Any code that uses it would have to be modified.
>
> Only non-breaking solution would be to keep both.  In the past, it has been suggested to have std.uni simply publicly import std.unicode (or analogous solution to some other module renaming).  You would always retain std.uni in this solution.
>
> -Steve

When `std.regexp` was deprecated, they used a pragma for the deprecation message:

https://github.com/D-Programming-Language/phobos/blob/2.062/std/regexp.d#L127L128

The same thing could be done for `std.uni`.


If there is a big plan to restructure Phobos then `std.uni` can be deprecated now, and be removed completely once the big backward compatibility break is done. If there is no such plan, the removal of `std.uni` will cause too much redundant breakage in no-longer-maintained libraries.

On Tue, 21 May 2013 13:08:46 -0400, Regan Heath <regan@netmail.co.nz> wrote:

> On Tue, 21 May 2013 17:52:10 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>
>> On Tue, 21 May 2013 12:43:01 -0400, Regan Heath <regan@netmail.co.nz> wrote:
>>
>>> On Tue, 21 May 2013 17:25:23 +0100, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>>
>>>> It has nothing to do with the name.  I think unicode is better.  But (allegedly) we have existing projects that use std.uni, which would break if we renamed.
>>>
>>> Wouldn't the old std.uni remain but deprecated?
>>>
>>
>> Deprecated functions don't compile.  Any code that uses it would have to be modified.
>
> dmd -d

Apparently, they DO compile with only a warning now.  This is better than before.

relying on dmd -d is a bad idea, since it's too blunt (ALL deprecated features in existence are now enabled without warnings).

>> Only non-breaking solution would be to keep both.  In the past, it has been suggested to have std.uni simply publicly import std.unicode (or analogous solution to some other module renaming).  You would always retain std.uni in this solution.
>
> Ick no.

With the advent that deprecated features are now warnings instead of errors, it might be doable, and just remove std.uni after a year or so.

What we need to establish what the cost is to projects that use std.uni currently.  I have no idea, since I don't use it.

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.

-Steve

On Tue, 21 May 2013 13:21:36 -0400, Idan Arye <GenericNPC@gmail.com> wrote:

> When `std.regexp` was deprecated, they used a pragma for the deprecation message:
>
> https://github.com/D-Programming-Language/phobos/blob/2.062/std/regexp.d#L127L128
>
> The same thing could be done for `std.uni`.

These past events have already been identified as "mistakes" by Walter and company.  I don't think we should follow that tack either.

-Steve

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

On Tuesday, 21 May 2013 at 17:12:14 UTC, Jacob Carlborg wrote:
> On 2013-05-21 14:51, 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.
>
> How about std.encoding.unicode to get a proper hierarchy into phobos.

+1

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

The problem is that people that need Unicode stuff see `std.utf` and assume that all Unicode related stuff are there.

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

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.

-- 
Simen