On Tuesday, 2 June 2015 at 13:39:54 UTC, ketmar wrote:
> On Tue, 02 Jun 2015 13:16:49 +0000, Namespace wrote:
>
>> On Tuesday, 2 June 2015 at 12:21:23 UTC, ketmar wrote:
>>> On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:
>>>
>>>> For me it looks ugly. But I would prefer final(false) instead of
>>>> !final.
>>>
>>> this opens a can of worms. should this be accepted too:
>>>   enum doItFinal = false;
>>>   final(doItFinal)
>>> ?
>>>
>>> or even
>>>   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
>>> ?
>> 
>> Yes, please.
>
> no, please. that's terrible, that's unpredictable, that's undebugable,
> that's slow. "we can make it dynamic" is not a good reason to actually
> make something dynamic.

So you dislike noexcept(condition) from C++? I like it. But no matter which syntax comes, important is that we get something to revert attributes. :)

On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
> I am working on dip which will try to addressed negation of attributes issue.
> http://wiki.dlang.org/DIP79

There are two subtly different things that "negation of attributes" can mean:
a) switch off an attribute that has been enabled by `attr:` or `attr { }`, and
b) switch on the opposite of an attribute.

I guess this is about a)? Option b) would have further use cases, e.g. `cast(!const) ...`.

Have you thought whether it should also be usable with UDAs? That would be more difficult than with normal attributes, because UDAs can be either values or types. Values would need to be comparable (opEquals).

I would also strongly recommend not to allow CTFE expressions, should the `attr(...)` form be chosen.

On Tue, 02 Jun 2015 14:34:10 +0000, Namespace wrote:

> from C++?

that alone is enough for me to say "burn it with fire!" ;-)

On Tuesday, 2 June 2015 at 14:46:47 UTC, ketmar wrote:
> On Tue, 02 Jun 2015 14:34:10 +0000, Namespace wrote:
>
>> from C++?
>
> that alone is enough for me to say "burn it with fire!" ;-)

Come on, be a little nostalgic. ;)

> This is by far not the only reason. It is just as well useful for all other attributes: const, pure, @safe/@system, @nogc, and maybe UDAs.
>
> It's long been recognized that a mechanism to switch off a scope-wide attribute would be useful.

Switching attributes on and off will make your code more complicated. If one doesn't use scope-wide attributes much then he won't need to switch them off.

On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
> On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
>> I am working on dip which will try to addressed negation of attributes issue.
>> http://wiki.dlang.org/DIP79
>
> You propose to add extra difficulty to the language and the only reason is "If you need add few methods which are virtual or variables, you are forced to put them before final:. This is too limiting.".
> I think it's a bad idea.

I agree.
On top of that, we have final { /* your final methods here */ } as a good alternative already.
Finally, as far as I know, D will change the behaviour to final by default. What happened with that? Anything decided?

On Tuesday, 2 June 2015 at 15:18:55 UTC, Dejan Lekic wrote:
> On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
>> On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
>>> I am working on dip which will try to addressed negation of attributes issue.
>>> http://wiki.dlang.org/DIP79
>>
>> You propose to add extra difficulty to the language and the only reason is "If you need add few methods which are virtual or variables, you are forced to put them before final:. This is too limiting.".
>> I think it's a bad idea.
>
> I agree.
> On top of that, we have final { /* your final methods here */ } as a good alternative already.
> Finally, as far as I know, D will change the behaviour to final by default. What happened with that? Anything decided?

http://dgame.github.io/dneeds/#final-by-default

On 6/2/15 11:18 AM, Dejan Lekic wrote:
> On Tuesday, 2 June 2015 at 12:13:47 UTC, ref2401 wrote:
>> On Tuesday, 2 June 2015 at 10:29:35 UTC, Daniel Kozak wrote:
>>> I am working on dip which will try to addressed negation of
>>> attributes issue.
>>> http://wiki.dlang.org/DIP79
>>
>> You propose to add extra difficulty to the language and the only
>> reason is "If you need add few methods which are virtual or variables,
>> you are forced to put them before final:. This is too limiting.".
>> I think it's a bad idea.
>
> I agree.
> On top of that, we have final { /* your final methods here */ } as a
> good alternative already.

No, this is not good enough. Let's say we have 20 member functions of a struct/class. All of them are @safe and @nogc. All but a few are nothrow, all but a few (a different few) are pure. Some are const, some aren't.

The most verbose way to do this is to put attributes on each function, blowing up all the signatures.

The most effective way would be to do this:

pure @safe nothrow @nogc {
...
}

And put attribute negations on the few odd functions that are different (including adding const, which I think appropriately belongs on each method that needs it).

But your confusing mechanism is to pull out functions from their natural order outside the scope, and attribute them separately. But that screws up documentation, and it may separate overloads which naturally belong together.

The best way is to label the oddballs, and we don't have a good way of doing that for most of the cases since the oddballs need less attributes.

> Finally, as far as I know, D will change the behaviour to final by
> default. What happened with that? Anything decided?

That is not happening. It was nixed by Andrei.

-Steve

On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
> On Tue, 02 Jun 2015 11:50:15 +0000, Namespace wrote:
> 
>> For me it looks ugly. But I would prefer final(false) instead of !final.
> 
> this opens a can of worms. should this be accepted too:
>   enum doItFinal = false;
>   final(doItFinal)
> ?
> 
> or even
>   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
> ?

[I'd assumed it was a rhetorical question, but after reading
 some of the followups...]

Of course.


Note that user defined attributes already work like that. This is a working D program, that uses GDC-specific extensions:

   import gcc.attribute;
   enum inl(alias B) = attribute(B?"forceinline":"noinline");

   @inl!(1) int f() { return 1; }
   @inl!(2+2==5) int g() { return 2; }
   enum e = g()-f()*2;
   @inl!e int i() { return 3; }
   int main() { return f()+g()+i(); }

The only alternative would be to force wrapping the whole (function) definition in a mixin statement -- that is not a practical solution and not scalable at all. You end up with multiple layers of string mixins and code written inside (nested!) string literals.

D has enough unnecessary special cases as it is (like built-in types
being special).

artur

On Tuesday, 2 June 2015 at 15:13:44 UTC, ref2401 wrote:
>
> Switching attributes on and off will make your code more complicated.

But not as complicated as working around the inability to do so already does.

-Wyatt