View mode: basic / threaded / horizontal-split · Log in · Help
July 12, 2011
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
>> 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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
Re: dmd 1.069 and 2.054 release
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
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home