On Tuesday, May 21, 2013 23:25:47 deadalnix wrote:
> 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 .

Except that std.uni already exists. It's just that we're adding a bunch more to it and improving the implementation of what's already there. Changing the name _will_break code, and as the benefits of renaming it are purely aesthetic, I don't think that it's worth it.

- Jonathan M Davis

On Tuesday, May 21, 2013 23:25:47 deadalnix wrote:
> 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 .

Except that std.uni already exists. It's just that we're adding a bunch more to it and improving the implementation of what's already there. Changing the name _will_break code, and as the benefits of renaming it are purely aesthetic, I don't think that it's worth it.

- Jonathan M Davis

On 2013-05-21, 22:12, Jonathan M Davis wrote:

> given that std.uni is actually one of the modules that you're _likely_ to have
> to give the full path to

Uhm, you *do* know D has renamed imports, right?

import uni = std.unicode; // Look ma, even shorter than std.uni!

-- 
Simen

On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
> 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.

More specifically, what I'm wondering is whether or not it's considered a breaking change if your code still compiles and works exactly as it did before except for perhaps a deprecation warning during the build?

I could be misunderstanding what the proposed public import solution would accomplish but it sounded like std.uni could be upgraded with Dmitry's improvements while getting a new module name that is easier for newcomers to find.  It sounded like win-win to me.

On Wednesday, May 22, 2013 22:07:24 Brad Anderson wrote:
> On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
> > 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.
> 
> More specifically, what I'm wondering is whether or not it's considered a breaking change if your code still compiles and works exactly as it did before except for perhaps a deprecation warning during the build?
> 
> I could be misunderstanding what the proposed public import solution would accomplish but it sounded like std.uni could be upgraded with Dmitry's improvements while getting a new module name that is easier for newcomers to find. It sounded like win-win to me.

Code wouldn't break immediately, but everyone would have to change their code eventually if we're deprecating std.uni in favor of std.unicode. So, we'd be forcing everyone to change their code purely for aesthetics, and we've almost entirely stopped doing that at this point. Walter and Andrei in particular are very much against renaming things at this point. The ROI on the change is too small.

- Jonathan M Davis

On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
> 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.
>

I don't understand why do we need to break code here. It is about introducing a new module.

On Thursday, 23 May 2013 at 00:43:04 UTC, deadalnix wrote:
> On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
>> 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.
>>
>
> I don't understand why do we need to break code here. It is about introducing a new module.

Doing it while keeping `std.uni` would create a duplication in both API and implementation, since `std.unicode` will contain all the functionality of `std.uni`. Eventually `std.uni` would have to be removed, because if Phobos would keep the old versions forever whenever a better version that does the same thing comes it will become very cluttered. Java walked that way.

Once the old `std.uni` will be finally removed - code will break.

On Thursday, 23 May 2013 at 01:24:42 UTC, Idan Arye wrote:
> Doing it while keeping `std.uni` would create a duplication in both API and implementation, since `std.unicode` will contain all the functionality of `std.uni`. Eventually `std.uni` would have to be removed, because if Phobos would keep the old versions forever whenever a better version that does the same thing comes it will become very cluttered. Java walked that way.
>
> Once the old `std.uni` will be finally removed - code will break.

Yes, that is exactly what is needed. Today we only consider not breaking at all, or breaking it as of next version of DMD and without any support for what come before the breakage. This boolean choice mindset isn't helping.

On Thursday, May 23, 2013 03:42:56 deadalnix wrote:
> On Thursday, 23 May 2013 at 01:24:42 UTC, Idan Arye wrote:
> > Doing it while keeping `std.uni` would create a duplication in both API and implementation, since `std.unicode` will contain all the functionality of `std.uni`. Eventually `std.uni` would have to be removed, because if Phobos would keep the old versions forever whenever a better version that does the same thing comes it will become very cluttered. Java walked that way.
> > 
> > Once the old `std.uni` will be finally removed - code will break.
> 
> Yes, that is exactly what is needed. Today we only consider not breaking at all, or breaking it as of next version of DMD and without any support for what come before the breakage. This boolean choice mindset isn't helping.

Every time that a library change is introduced it's done in a way that allows the programmer time to migrate their code. I'm not aware of any case thus far where we've purposefully changed library code in a manner which immediately broke user code. We don't even do that with the compiler. The problem is all of the times that it happens on accident (particularly with compiler regressions). So, regardless, we're not going to immediately break code out from under people.

So, the question is whether it's worth making people change their code sometime between when we make the change and when std.uni finally goes away. And I don't think that making people change their code is worth it regardless of how gradual it is. std.uni is not as good a name as std.unicode, but it's just not worth forcing people to change their code in order to fix it. If we keep trying to tweak the names of modules and functions and whatnot, we'll never be in a state where people can rely on their code compiling across compiler versions. Tweaking some stuff is necessary, and we did a lot in the past to fix symbol names, but we've pretty much stopped doing that, and we have to draw the line somewhere. The general push has been to stabilize our the compiler and Phobos, and tweaking names does not help with that and generally has a low ROI.

- Jonathan M Davis

On Thursday, 23 May 2013 at 03:15:44 UTC, Jonathan M Davis wrote:
> Every time that a library change is introduced it's done in a way that allows
> the programmer time to migrate their code. I'm not aware of any case thus far
> where we've purposefully changed library code in a manner which immediately
> broke user code. We don't even do that with the compiler. The problem is all
> of the times that it happens on accident (particularly with compiler
> regressions). So, regardless, we're not going to immediately break code out
> from under people.
>

Inconsistent naming is the #1 complaint about PHP. After using D for years, I still don't know what some modules are about in phobos.

Yeah, it is worth it.