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 http://msdn.microsoft.com/en-us/library/System.ObsoleteAttribute.aspx

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 done with a user defined attribute instead?
>>
>> Anyone want to take on the challenge?
>
> I think it's a bit too soon to start replacing language features with UDA.
>

Yes, but that should be the goal !

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 flag for outputting the result of a macro.

-- 
/Jacob Carlborg

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 defined attribute instead?
>
> Anyone want to take on the challenge?

Good plan. On a side note when can we expect some progress on stabilizing the language and fixing ~2000 bugs? After a couple of more random unnecessary breaking changes, or do you anticipate it happening before that?

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 macro? In that case the compiler should have a flag for
> outputting the result of a macro.
>

I'm talking about the ability for the macro to modify the macroed code, not only to wrap it.

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 function and can do whatever you want with it.

It's just happens so that in this example it's enough to wrap the function. Actually, my "implementation" didn't wrap the function, it injected the "static assert" into the function body.

-- 
/Jacob Carlborg

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?
>
> Anyone want to take on the challenge?

That *cannot* fix the problem.
The problem is not with the deprecated attribute at all, it's with the command line switches.

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 with a user defined attribute instead?
>>
>> Anyone want to take on the challenge?
>
> That *cannot* fix the problem.
> The problem is not with the deprecated attribute at all, it's with the
> command line switches.

+1.

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

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 with a user defined attribute instead?
>>
>> Anyone want to take on the challenge?
>
> That *cannot* fix the problem.
> The problem is not with the deprecated attribute at all, it's with the
> command line switches.

That and it taking a looong time to add sensible "don't use 'this' use 'that'" messages to deprecated.

-- 
Dmitry Olshansky