On Saturday, 17 November 2012 at 17:42:03 UTC, Alex Rønne
Petersen wrote:
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.
It's just an alternative compilation mode.
And may be people shouldn't go
On Sunday, November 18, 2012 11:00:09 Kagamin wrote:
You compile with -d because previously the build broke, so you
know you use deprecated features.
Except that then you forget about it and never get around to updating your
code so that it doesn't use the deprecated features, and when they're
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
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
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.
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),
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
On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
On 07/11/12 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the
deprecated
attribute - it's all-or-nothing approach, poor messages, etc.
Each
change in it changes the language and the compiler.
On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra
wrote:
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright
wrote:
I know there's been some long term unhappiness about the
deprecated attribute - it's all-or-nothing approach, poor
messages, etc. Each change in it changes the
On 11-11-2012 14:18, Leandro Lucarella wrote:
On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra wrote:
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor
On 11-11-2012 14:09, Leandro Lucarella wrote:
On Thursday, 8 November 2012 at 08:13:37 UTC, Don Clugston wrote:
On 07/11/12 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change
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.
David
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
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,
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
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
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…
On 09-11-2012 19:06, Kagamin wrote:
On Friday, 9 November 2012 at 08:49:28 UTC, Walter Bright wrote:
On 11/8/2012 12:13 AM, Don Clugston wrote:
That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's with
the command
line switches.
Of interest:
On 11/8/2012 12:13 AM, Don Clugston wrote:
That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's with the command
line switches.
Of interest:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3394.html
Looks like another D feature moving into
On 11/9/12, Walter Bright newshou...@digitalmars.com wrote:
On 11/8/2012 12:13 AM, Don Clugston wrote:
That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's with the
command
line switches.
Of interest:
On Friday, November 09, 2012 00:49:19 Walter Bright wrote:
On 11/8/2012 12:13 AM, Don Clugston wrote:
That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's with the
command line switches.
Of interest:
On Friday, 9 November 2012 at 08:49:28 UTC, Walter Bright wrote:
On 11/8/2012 12:13 AM, Don Clugston wrote:
That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's
with the command
line switches.
Of interest:
On 07/11/12 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done with a user defined attribute instead?
On 08-11-2012 09:13, Don Clugston wrote:
On 07/11/12 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done
11/8/2012 12:13 PM, Don Clugston пишет:
On 07/11/12 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done
Am 07.11.2012 03:55, schrieb Andrei Alexandrescu:
On 11/7/12 1:56 AM, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it
On 11/06/2012 10:03 PM, monarch_dodra wrote:
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the
On 2012-11-07 04:40, Walter Bright wrote:
I didn't say remove it. I said deprecate it.
I would assume that if a feature is getting deprecated it will be
removed somewhere in the future, otherwise what's the reason for
deprecating it?
--
/Jacob Carlborg
On 2012-11-07 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done with a user defined attribute instead?
On 2012-11-07 04:41, Walter Bright wrote:
It would be interesting to see where those pain points are, and whether
a general hook mechanism for user plugins would be a good idea.
I think that with UDA in combination with AST macros it could work.
@deprecated(don't use this feature any more)
[OT] deprecated attribute is yet not correctly implemented by the compiler.
http://d.puremagic.com/issues/show_bug.cgi?id=7619
Kenji Hara
2012/11/7 Walter Bright newshou...@digitalmars.com:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing
On Wednesday, 7 November 2012 at 02:55:38 UTC, Andrei
Alexandrescu wrote:
I don't think that's possible. One would need a mechanism to
hook into all calls to a function (adorned with a specific
attribute) and emit the message during compilation. That is
missing.
The attribute can be declared
Le 07/11/2012 04:41, Walter Bright a écrit :
On 11/6/2012 6:55 PM, Andrei Alexandrescu wrote:
I don't think that's possible. One would need a mechanism to hook into
all calls
to a function (adorned with a specific attribute) and emit the message
during
compilation. That is missing.
It would
Le 07/11/2012 11:42, Jacob Carlborg a écrit :
On 2012-11-07 04:41, Walter Bright wrote:
It would be interesting to see where those pain points are, and whether
a general hook mechanism for user plugins would be a good idea.
I think that with UDA in combination with AST macros it could work.
Le 07/11/2012 11:43, Jacob Carlborg a écrit :
On 2012-11-07 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be
On Wednesday, 7 November 2012 at 13:43:39 UTC, Kagamin wrote:
http://msdn.microsoft.com/en-us/library/system.threadstaticattribute.aspx
http://msdn.microsoft.com/en-us/library/System.Diagnostics.ConditionalAttribute.aspx
Oh, and C# has ObsoleteAttribute
On 2012-11-07 15:10, deadalnix wrote:
Yes, but that should be the goal !
Absolutely.
--
/Jacob Carlborg
On 2012-11-07 15:08, deadalnix wrote:
This is nice, but lack the possible to explore the internal of the
function and to surgery in it :D
Still a step forward.
I'm not entirely sure I understand. Do you mean that you won't see the
output of the macro? In that case the compiler should have a
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
I know there's been some long term unhappiness about the
deprecated attribute - it's all-or-nothing approach, poor
messages, etc. Each change in it changes the language and the
compiler.
Perhaps it could be done with a user
Le 07/11/2012 18:58, Jacob Carlborg a écrit :
On 2012-11-07 15:08, deadalnix wrote:
This is nice, but lack the possible to explore the internal of the
function and to surgery in it :D
Still a step forward.
I'm not entirely sure I understand. Do you mean that you won't see the
output of the
On 2012-11-07 20:32, deadalnix wrote:
I'm talking about the ability for the macro to modify the macroed code,
not only to wrap it.
I'm still not entirely sure what you mean but in most AST macro systems
in other languages like Sacal, Nimrod and Nemerle you will get the
complete AST of the
I know there's been some long term unhappiness about the deprecated attribute -
it's all-or-nothing approach, poor messages, etc. Each change in it changes the
language and the compiler.
Perhaps it could be done with a user defined attribute instead?
Anyone want to take on the challenge?
On 07-11-2012 00:56, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done with a user defined attribute instead?
Le 07/11/2012 00:56, Walter Bright a écrit :
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done with a user defined attribute instead?
On Tuesday, November 06, 2012 15:56:09 Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each change
in it changes the language and the compiler.
Perhaps it could be done with a user defined
Walter Bright:
Perhaps it could be done with a user defined attribute instead?
Maybe we need more ways to better attach some semantics to UDAs
:-)
Bye,
bearophile
On 11/7/12 1:56 AM, Walter Bright wrote:
I know there's been some long term unhappiness about the deprecated
attribute - it's all-or-nothing approach, poor messages, etc. Each
change in it changes the language and the compiler.
Perhaps it could be done with a user defined attribute instead?
On 11/6/2012 6:55 PM, Andrei Alexandrescu wrote:
I don't think that's possible. One would need a mechanism to hook into all calls
to a function (adorned with a specific attribute) and emit the message during
compilation. That is missing.
It would be interesting to see where those pain points
On 11/6/2012 5:12 PM, Jonathan M Davis wrote:
And how would this interact with -d? It's one thing to give symbols attributes
which can be examined at compile time. It's quite another to make it so that
they don't compile without a specific compiler flag.
The -version flag can be used to turn
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
I know there's been some long term unhappiness about the
deprecated attribute - it's all-or-nothing approach, poor
messages, etc. Each change in it changes the language and the
compiler.
I *just* had a conversation about this,
On Wednesday, 7 November 2012 at 07:03:55 UTC, monarch_dodra
wrote:
-- : Deprecated stuff just can't be used
-d : You can use deprecated stuff, but you get no warning
-dw : You can use deprecated stuff, and are served with a
warning
Or some other default (I don't really care), but there needs
On Wednesday, November 07, 2012 08:03:54 monarch_dodra wrote:
On Tuesday, 6 November 2012 at 23:56:13 UTC, Walter Bright wrote:
I know there's been some long term unhappiness about the
deprecated attribute - it's all-or-nothing approach, poor
messages, etc. Each change in it changes the
52 matches
Mail list logo
