View mode: basic / threaded / horizontal-split · Log in · Help
November 11, 2012
Re: deprecate deprecated?
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
November 11, 2012
Re: deprecate deprecated?
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
November 11, 2012
Re: deprecate deprecated?
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
November 11, 2012
Re: deprecate deprecated?
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
November 11, 2012
Re: deprecate deprecated?
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
November 12, 2012
Re: deprecate deprecated?
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.
November 12, 2012
Re: deprecate deprecated?
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
November 17, 2012
Re: deprecate deprecated?
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
November 17, 2012
Re: deprecate deprecated?
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
November 17, 2012
Re: deprecate deprecated?
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home