On Sunday, November 11, 2012 15:01:14 Alex Rønne Petersen wrote:
> I'm against that pull request. Not because I think it isn't useful, but because I think it doesn't fix the problem.
> 
> Usage of deprecated symbol(s) should be a warning by default and the new option should be used to turn that into an error; not the other way around.

Agreed. Otherwise, you can't deprecate something without immediately breaking code, which means that if you're trying to never immediately break people's code when making a change (which is the position that Phobos is in), then you can't use deprecated. "Scheduling" stuff for deprecation has helped, but it hasn't really fixed all that much. Making it so that deprecated emited a warning instead of an error and otherwise did not affect compilation _would_ fix it (as long as -w didn't affect it), but then a flag for making it an error is needed so that people can be sure that they've completely removed all deprecated features from their code (due to how deprecated affects conditional compilation).

- Jonathan M Davis

On Sunday, November 11, 2012 16:16:33 David Nadlinger wrote:
> On Sunday, 11 November 2012 at 13:59:59 UTC, Alex Rønne Petersen
> 
> wrote:
> > Yes, definitely warnings by default. The current system makes the deprecated keyword useless in practice for libraries
> 
> +1. Or even plus a whole lot more, if I had multiple votes.

They're obviously not regulated, so just go for typeof(vote).max. ;)

- Jonathan M Davis

On Sunday, 11 November 2012 at 21:15:42 UTC, Jonathan M Davis wrote:
> They're obviously not regulated, so just go for typeof(vote).max. ;)

I'm afraid this would backfire – assuming that votes are integral, if somebody else also supported the issue after me, then the votes would either be reset or we would have undefined behavior. ;)

David

On Sunday, November 11, 2012 23:06:45 David Nadlinger wrote:
> On Sunday, 11 November 2012 at 21:15:42 UTC, Jonathan M Davis
> 
> wrote:
> > They're obviously not regulated, so just go for
> > typeof(vote).max. ;)
> 
> I'm afraid this would backfire – assuming that votes are integral, if somebody else also supported the issue after me, then the votes would either be reset or we would have undefined behavior. ;)

No. This is D. It wouldn't be undefined at all. It would just wrap around to typeof(vote).min. That should be completely defined for integral types (for that matter, it's well-defined in C land too. It's just that you have issues with the size of the type changing depending on which machine you compile on). I'm not sure what happens with non-integral types though. I _was_ pretty much assuming an integral type.

But yes, that would be a problem, because you would have nullified all future votes. typeof(vote.max) / 2 it is then. ;)

- Jonathan M Davis

On Sunday, 11 November 2012 at 22:28:58 UTC, Jonathan M Davis wrote:
> for that matter, it's well-defined in C land too.

Signed integer overflow isn't well-defined in C; only operations on unsigned types are guaranteed to wrap around. And since people might also want to downvote a proposal…

Anyway, what was the topic? ;)

David

On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis wrote:
> Agreed. Otherwise, you can't deprecate something without immediately breaking
> code, which means that if you're trying to never immediately break people's
> code when making a change (which is the position that Phobos is in), then you
> can't use deprecated.
>
> [SNIP]
>
> - Jonathan M Davis

The problem with this approach is that the step after marking something deprecated is removing the function. So people using something deprecated go from
- "warning: Don't use this" (yeah... whatever...)
- "Your function has disappeared". (Oh oh)

At this point, they're fucked bad because they can't even bypass the problem with an extra -d command line option, which (in my eyes) is "pretty please, I'll change it, just give me a bit more time".

IMO, there *NEEDS* to be some way of saying
- "this _will_ be deprecated soon (marked for deprecation), you should consider migrating to something else. here is you warning."
and
- "This is already deprecated. Here is your error. You can *still* use it with -d, but migrate away soon, because this function is about to disappear"

----
If you can't make this distinction, then you also run into the danger of not breaking anybody's code when deprecating stuff, but having to keep deprecated stuff around forever.

On Monday, November 12, 2012 12:09:34 monarch_dodra wrote:
> IMO, there *NEEDS* to be some way of saying
> - "this _will_ be deprecated soon (marked for deprecation), you
> should consider migrating to something else. here is you warning."
> and
> - "This is already deprecated. Here is your error. You can
> *still* use it with -d, but migrate away soon, because this
> function is about to disappear"
> 
> ----
> If you can't make this distinction, then you also run into the danger of not breaking anybody's code when deprecating stuff, but having to keep deprecated stuff around forever.

Sure, it would be nice to have that distinction, but regardless of what you do, if the user doesn't fix their code, it'll break eventually when the deprecated symbol is removed. Because we have -d, they can completely ignore deprecated stuff even though it currently gives an error, which puts them in exactly the same boat that they'll be if they use -d if using deprecated stuff is a warning, and if they don't use -d, they're always being bugged about it, so it's basically the same as -d now as far as compilation goes, but they'll be made aware of the problem.

The _only_ downside that I see is that if someone is stupid enough to leave in a sea of warnings (which is much harder to do in D than other languages due to Walter's dislike of warnings), the deprecation messages might be buried. But as long as you can see them and/or you compile with -de (or whatever the flag is that makes them errors again), then I don't see problem.

The fact that you go from warning to gone (if no extra flags are used) isn't a problem as far as I can see. It's really not that much different from what we have now as far as people ignoring fixing deprecated stuff goes. It just means that people's code won't break immediately when stuff is deprecated.

And sure, there's a possibility that stuff will stick around for a ridiculously long time, but we have that problem _now_ when deprecated generates an error by default.

- Jonathan M Davis

On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis wrote:
>> Usage of deprecated symbol(s) should be a warning by default and the new
>> option should be used to turn that into an error; not the other way around.
>
> Agreed. Otherwise, you can't deprecate something without immediately breaking
> code, which means that if you're trying to never immediately break people's
> code when making a change (which is the position that Phobos is in), then you
> can't use deprecated.

fixing the broken code is as simple as
make -DDFLAGS=-d

On 17-11-2012 13:53, Kagamin wrote:
> On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis wrote:
>>> Usage of deprecated symbol(s) should be a warning by default and the new
>>> option should be used to turn that into an error; not the other way
>>> around.
>>
>> Agreed. Otherwise, you can't deprecate something without immediately
>> breaking
>> code, which means that if you're trying to never immediately break
>> people's
>> code when making a change (which is the position that Phobos is in),
>> then you
>> can't use deprecated.
>
> fixing the broken code is as simple as
> make -DDFLAGS=-d

And that's the entire problem.

People shouldn't have to go in and change anything to make code build just because something has been deprecated.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Saturday, November 17, 2012 13:53:45 Kagamin wrote:
> On Sunday, 11 November 2012 at 21:14:10 UTC, Jonathan M Davis
> 
> wrote:
> >> Usage of deprecated symbol(s) should be a warning by default
> >> and the new
> >> option should be used to turn that into an error; not the
> >> other way around.
> > 
> > Agreed. Otherwise, you can't deprecate something without
> > immediately breaking
> > code, which means that if you're trying to never immediately
> > break people's
> > code when making a change (which is the position that Phobos is
> > in), then you
> > can't use deprecated.
> 
> fixing the broken code is as simple as
> make -DDFLAGS=-d

True, but you're still breaking code, and Walter is _very_ much against that. I think that if it were entirely up to him, no API would change ever. Also, if you start compiling with -d, then you have no idea what is and isn't deprecated, and then you're that much more screwed when a deprecated symbol is actually removed. It just would work a _lot_ better if deprecated warned by default. Then it's made clear that the code needs to be changed but the build isn't broken, and the maintainers have time to fix it before their code actually breaks and with the warnings still there reminding them rather than simply being made to go away with -d and then forgotten.

- Jonathan M Davis