July 12, 2011
In general good work!

But again phobos makes a simple std.string function unCTFEable.
Now I have to use an ugly hack to achieve something as simple as toUpper:

mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );
July 12, 2011
On 12.07.2011 15:10, Trass3r wrote:
> In general good work!
>
> But again phobos makes a simple std.string function unCTFEable.
> Now I have to use an ugly hack to achieve something as simple as toUpper:
>
> mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );

Damn i found that too and wanted to mention it in the dmd-beta list b4 release. But the workaround is simple. At least this one was fixed:

http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000773.html

Cause that was making cl4d with all its string mixins pretty much unbuildable at all.
July 12, 2011
>> Now I have to use an ugly hack to achieve something as simple as toUpper:
>>
>> mixin( (){char[] tmp = "...".dup; toUpperInPlace(tmp); return tmp;}() );
>
> Damn i found that too and wanted to mention it in the dmd-beta list b4 release. But the workaround is simple. At least this one was fixed:
>
> http://lists.puremagic.com/pipermail/dmd-beta/2011-July/000773.html
>
> Cause that was making cl4d with all its string mixins pretty much unbuildable at all.

Yeah I've done some crazy shit in the cl4d code :D
But in the end that was just another workaround cause template mixins couldn't mixin constructors.
Good news: this seems to have been fixed.
Bad news: there still is another problem. I asked about it in D.learn.


btw, that problem you reported, where did it occur in cl4d?
July 12, 2011
Jonathan M Davis, el 11 de julio a las 22:21 me escribiste:
> On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote:
> > Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
> > > > Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.
> > > 
> > > True. But when we're dealing with messages for something which is scheduled for deprecation
> > 
> > What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept.
> 
> The idea is to have 3 stages while deprecating something.
> 
> 1. Scheduled for Deprecation.
> 2. Deprecated.
> 3. Removed.
> 
> When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol.

If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors.

Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
No tengo alas, como un planeador.
No tengo luces, como un plato volador.
Perdi mi rumbo soy un auto chocador.
July 12, 2011
On 2011-07-12 10:07, Leandro Lucarella wrote:
> Jonathan M Davis, el 11 de julio a las 22:21 me escribiste:
> > On Tuesday 12 July 2011 01:28:11 Leandro Lucarella wrote:
> > > Jonathan M Davis, el 11 de julio a las 18:15 me escribiste:
> > > > > Despite the confusing non-standard descriptions in --help, -w is the "Treat warnings as errors" setting, so it *should* stop compilation - that's the whole point of -w. The proper "Turn warnings on" setting is -wi, not -w.
> > > > 
> > > > True. But when we're dealing with messages for something which is scheduled for deprecation
> > > 
> > > What's the point of "scheduled for deprecation" anyway? Things are deprecated, or aren't, anything else should be in the documentation. You can always use deprecated features using a compiler, so again... what's the point of "scheduled for deprectation"? I can't really understand that concept.
> > 
> > The idea is to have 3 stages while deprecating something.
> > 
> > 1. Scheduled for Deprecation.
> > 2. Deprecated.
> > 3. Removed.
> > 
> > When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol.
> 
> If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors.
> 
> Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not.

Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code.

Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, "scheduled for deprecation" isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D.

When a symbol is deprecated, it's an error to use it unless you compile with - d. So, there is no warning about using deprecated stuff. It's an outright error. It just so happens that you can turn it off if you need to (hopefully as a quick fix). And given that deprecating a symbol introduces errors into the code of anyone who uses that symbol, informing people ahead of time gives them the opportunity to change their code before it breaks. The result is a much smoother process.

1. Something is scheduled for deprecation, so programmers then have the time to figure out what they're going to do to change their code, and they have time to make the changes. Nothing breaks. No one is forced to make immediate changes.

2. The symbol is then deprecated. Anyone who did not take the time to make changes as they were told that they were going to have to do then has broken code, but they have the quick fix of compiling with -d if they need to. They're still going to have to figure out what they're going to do about changing their code, and they're forced to look at the problem at least far enough to enable -d, but their code can still work with some changes to their build scripts.

3. The symbol is outright removed. Programmers have had ample time to change their code, and if they haven't, they now have to. But they were told that the symbol was going away and had to have made changes to their build scripts to even use it this long, so the developer of the library hasn't just screwed them over.

The idea is to provide a smooth path for necessary changes. And just deprecating something out of the blue does _not_ do that.

- Jonathan M Davis
July 12, 2011
Jonathan M Davis, el 12 de julio a las 18:12 me escribiste:
> > > When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol.
> > 
> > If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors.
> > 
> > Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not.
> 
> Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code.
> 
> Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, "scheduled for deprecation" isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D.

So then, why don't we fix it (patch attached, you can apply it with 'git am file'). I think -di is the real solution to the problem. Things are deprecated or not, and people want to be informed if they are using something deprecated or not. Scheduled for deprecation seems to be a way to say "show me a deprecation message", not a real "state".

> When a symbol is deprecated, it's an error to use it unless you compile with - d. So, there is no warning about using deprecated stuff. It's an outright error. It just so happens that you can turn it off if you need to (hopefully as a quick fix). And given that deprecating a symbol introduces errors into the code of anyone who uses that symbol, informing people ahead of time gives them the opportunity to change their code before it breaks. The result is a much smoother process.

OK, then we should fix the compiler (again, patch attached). -di is the solution. My patch doesn't change the defaults, but if people think is better to show deprecation errors by default, it can be trivially changed.

> 1. Something is scheduled for deprecation, so programmers then have the time to figure out what they're going to do to change their code, and they have time to make the changes. Nothing breaks. No one is forced to make immediate changes.

This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is "scheduled for removal", so "scheduled for deprecation" is "scheduled for scheduled for removal", it makes no sense. Fix the compiler!

> 2. The symbol is then deprecated. Anyone who did not take the time to make changes as they were told that they were going to have to do then has broken code, but they have the quick fix of compiling with -d if they need to. They're still going to have to figure out what they're going to do about changing their code, and they're forced to look at the problem at least far enough to enable -d, but their code can still work with some changes to their build scripts.
> 
> 3. The symbol is outright removed. Programmers have had ample time to change their code, and if they haven't, they now have to. But they were told that the symbol was going away and had to have made changes to their build scripts to even use it this long, so the developer of the library hasn't just screwed them over.
> 
> The idea is to provide a smooth path for necessary changes. And just deprecating something out of the blue does _not_ do that.

Unless we fix the compiler :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
All evidence has been buried
All tapes have been erased
But your footsteps give you away
So you're backtracking


July 12, 2011
On 2011-07-12 13:52, Leandro Lucarella wrote:
> Jonathan M Davis, el 12 de julio a las 18:12 me escribiste:
> > > > When a symbol has been deprecated, -d is required to compile any code using that symbol. So, deprecation breaks code. You either have to change your code so that it doesn't use the deprecated symbol, or you have to change your build scripts to use -d. In either case, deprecating a symbol without warning is going to cause problems for anyone maintaining code which uses that symbol.
> > > 
> > > If you don't want your code to break when something is deprecated, you should *always* compile with -d, so no, you don't have to change the build system if you always have -d. Maybe all needed is just a -di (as in -wi), where deprecation are informed but not treated as errors.
> > > 
> > > Scheduled for deprecation makes no sense, it's a user decision to use deprecated code or not, and if should be a user decision if he/she wants a warning about deprecated stuff or not.
> > 
> > Except, of course, that good cood generally won't use anything that's deprecated, since the deprecated item is going to go away. The user can decide to use -d and use deprecated code if it makes sense for them, but that really should be decided on a case-by-case basis. Most programmers won't want to use -d. So, they're not going to compile with -d by default. So, deprecating something will break their code. By saying that you're scheduling something for deprecation, you're giving the user time to deal with the change before it breaks their code.
> > 
> > Now, I could see an argument for changing how deprecation works so that deprecated has no effect unless a flag turns it on, in which case, the user is deciding whether they want to warned about using deprecated code. In such a case, "scheduled for deprecation" isn't quite as necessary, but then you're just going to break everyone's code when you remove the function (at least everyone who didn't use the flag to be warned about using deprecated symbols). And rather than being able to then change their build scripts to use -d while they fix the problem, they then _have_ to go change their code (or not upgrade their libraries) in order for their code to compile. But that's not how deprecated works in D.
> 
> So then, why don't we fix it (patch attached, you can apply it with 'git am file'). I think -di is the real solution to the problem. Things are deprecated or not, and people want to be informed if they are using something deprecated or not. Scheduled for deprecation seems to be a way to say "show me a deprecation message", not a real "state".
> 
> > When a symbol is deprecated, it's an error to use it unless you compile with - d. So, there is no warning about using deprecated stuff. It's an outright error. It just so happens that you can turn it off if you need to (hopefully as a quick fix). And given that deprecating a symbol introduces errors into the code of anyone who uses that symbol, informing people ahead of time gives them the opportunity to change their code before it breaks. The result is a much smoother process.
> 
> OK, then we should fix the compiler (again, patch attached). -di is the solution. My patch doesn't change the defaults, but if people think is better to show deprecation errors by default, it can be trivially changed.
> 
> > 1. Something is scheduled for deprecation, so programmers then have the time to figure out what they're going to do to change their code, and they have time to make the changes. Nothing breaks. No one is forced to make immediate changes.
> 
> This is what deprecated is for! Removing stuff breaks code, not deprecating stuff! Deprecated really is "scheduled for removal", so "scheduled for deprecation" is "scheduled for scheduled for removal", it makes no sense. Fix the compiler!
> 
> > 2. The symbol is then deprecated. Anyone who did not take the time to make changes as they were told that they were going to have to do then has broken code, but they have the quick fix of compiling with -d if they need to. They're still going to have to figure out what they're going to do about changing their code, and they're forced to look at the problem at least far enough to enable -d, but their code can still work with some changes to their build scripts.
> > 
> > 3. The symbol is outright removed. Programmers have had ample time to change their code, and if they haven't, they now have to. But they were told that the symbol was going away and had to have made changes to their build scripts to even use it this long, so the developer of the library hasn't just screwed them over.
> > 
> > The idea is to provide a smooth path for necessary changes. And just deprecating something out of the blue does _not_ do that.
> 
> Unless we fix the compiler :)

This doesn't really fix the problem. Deprecating something is still going to break code unless people actively try and avoid it by using -di, so deprecating stuff without informing people beforehand is going to break a lot of code. Perhaps the language should be change so that using deprecated stuff generates a warning rather than an error, but unless you change the default behavior, the original problem still stands.

If you want how the language treats deprecated to change, then feel free to create a pull request and try and talk Walter into it. Arguably, warning about deprecation and then only failing to compile when the deprecated stuff is actually removed is the better way to handle things. But that's not how D is designed (probably at least in part because Walter doesn't really believe in warnings). So, feel free to try and talk Walter into it, but unless the default behavior is changed, deprecating something is going to silently break people's code unless you tell them about it first (which is the point of scheduling something for deprecation).

- Jonathan M Davis
July 12, 2011
On 2011-07-12 16:52:10 -0400, Leandro Lucarella <luca@llucax.com.ar> said:

> This is what deprecated is for! Removing stuff breaks code, not
> deprecating stuff! Deprecated really is "scheduled for removal", so
> "scheduled for deprecation" is "scheduled for scheduled for removal", it
> makes no sense. Fix the compiler!

Actually it sometime makes sense that you'd schedule something to be later scheduled for removal. If there is no replacement for a certain feature, making it deprecated is just a nuisance since the compiler will complain about the problem but you have no alternative yet.

Now, I think the argument for scheduling things for deprecation is just an extreme of that: deprecating things is a nuisance because it breaks code, so we'll schedule them to be deprecated later. But then we add a warning for those things scheduled for deprecation because we don't want people to use them, and "scheduled for deprecation" has just become a synonym for "deprecated but not yet breaking your code". Fixing deprecated to not break code by default is a better option, I think.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

July 12, 2011
Jonathan M Davis wrote:
> Deprecating something is still going to break code

Breaking with deprecated is an entirely different kind of breakage than removing something.

deprecated means simply "please don't use this specific thing". You can tell it "shut up I know better than you" and be on your way.

It's in your face enough that you can change it right there and then if you want to, but it's easy enough to shut it up too.


Here's my preference list for changes:

Top preference: don't change stuff.

Next: use the deprecated attribute

Next: versioned scheduled to be deprecated messages. I don't like being spammed every time I compile.

Next: scheduled to be deprecated messages as they are now

Last: removing it entirely. (this should be very, very rare especially if we want to be called stable. Nothing has pissed me off more with the last few releases than Phobos losing functionality.)
July 12, 2011
On 2011-07-12 15:09, Adam D. Ruppe wrote:
> Jonathan M Davis wrote:
> > Deprecating something is still going to break code
> 
> Breaking with deprecated is an entirely different kind of breakage than removing something.
> 
> deprecated means simply "please don't use this specific thing". You can tell it "shut up I know better than you" and be on your way.
>
> It's in your face enough that you can change it right there and then if you want to, but it's easy enough to shut it up too.

True. But Walter has been pretty insistent that things not be deprecated without warning first, because code which compiled perfectly before doesn't anymore, even if all you have to do is change your build scripts.

Now, as for the "scheduled for deprecation" messages, we can stop doing that. But then the documentation is going to be the only thing warning anyone, and then code is going to get broken when stuff is actually deprecated. Given the fact that you can use -d, that's not the end of the world. But it does mean that deprecation is going to tend to come out of nowhere for most people, and Walter has been very adamant about avoiding suddenly breaking people's code - even by requiring them to add -d to their build scripts.

So, if most people don't want the messages, then the messages will go away. But that means that people actually need to pay attention to the changelog and documentation.

> Here's my preference list for changes:
> 
> Top preference: don't change stuff.
> 
> Next: use the deprecated attribute
> 
> Next: versioned scheduled to be deprecated messages. I don't like being spammed every time I compile.
> 
> Next: scheduled to be deprecated messages as they are now
> 
> Last: removing it entirely. (this should be very, very rare especially if we want to be called stable. Nothing has pissed me off more with the last few releases than Phobos losing functionality.)

The current plan is that _everything_ which gets deprecated will be removed. Stuff which is deprecated is not intended to stick around. Now, it should be pretty rare that deprecated stuff doesn't have a replacement. Outright removing functionality should be very rare indeed. It may happen in a few cases where the functionality just isn't generally useful, but overall, it should be rare.

Deprecation is likely to fall primarily in 3 categories at this point:

1. Renaming stuff to follow Phobos' naming conventions. A lot of this was fixed with 2.054, but there's still some left to do. For the most part though, this should be a set of fixes which will be done fairly soon and then we won't have to make those kind of changes again.

2. Small redesigns of older functionality. The prime case that I can think of is that there has been talk of replacing the use of patterns in std.string with uses of std.regex.Regex.

3. Full module redesigns due to the need of serious improvement. std.datetime replacing std.date would be a prime example of this, but there are a few other modules which are supposed to be redesigned (e.g. std.xml and std.stream).

The idea at least is that these sort of changes should be taking place fairly soon and that we then won't need to do any of that kind of thing anymore (or at least only very rarely). The review process should catch most of these sort of issues before they actually get into Phobos in the first place. But some code has not aged well as D and Phobos have changed, and Phobos has not always been consistent in naming, and that needs to be fixed sooner rather than later.

- Jonathan M Davis