>This in theory reduce some kind of bugs, when one forget to mark method as virtual.

It doesn't reduce bugs, it introduces noticeable bugs and slightly lowers performance. All at the benefit of not having to write' virtual'.

/pedantic

As for the actual DIP, I don't like final(false). It's simply far too verbose, and a double negative (not not overridable), same for @nogc(false). I slightly prefer !final (though it's again a double negative, but at least it's more consistent with bools and not function invocation), but even then it's not a nice solution.  Only decent one I can think of though, short of adding virtual.

On Tue, 02 Jun 2015 14:53:23 +0000, Namespace wrote:

> 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. ;)

that's it: i always wanted to give C++ some smelly napalm hello.

On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d wrote:

> 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.

this is bad. it smells. it adds almost nothing in terms of uniformity. and i'm sure that Hackerpilot will be happy to know that he now needs a full-blown D interpreter to determine if some method is virtual or not. ;- )

On 06/03/15 01:41, ketmar via Digitalmars-d wrote:
> On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d wrote:
> 
>> On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
>>> this opens a can of worms. should this be accepted too:
>>>   enum doItFinal = false;
>>>   final(doItFinal)
>>> ?
>>>
>>> or even
>>>   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
>>> ?

>> Of course.
> 
> this is bad. it smells. it adds almost nothing in terms of uniformity. and i'm sure that Hackerpilot will be happy to know that he now needs a full-blown D interpreter to determine if some method is virtual or not. ;-)

An interpreter is required anyway.

And that is, btw, why any simple dfix-like tool can not work with a language like D, where the *norm* is programs that write programs.

artur

On Wed, 03 Jun 2015 02:40:55 +0200, Artur Skawina via Digitalmars-d wrote:

> On 06/03/15 01:41, ketmar via Digitalmars-d wrote:
>> On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d wrote:
>> 
>>> On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
>>>> this opens a can of worms. should this be accepted too:
>>>>   enum doItFinal = false;
>>>>   final(doItFinal)
>>>> ?
>>>>
>>>> or even
>>>>   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
>>>> ?
> 
>>> Of course.
>> 
>> this is bad. it smells. it adds almost nothing in terms of uniformity. and i'm sure that Hackerpilot will be happy to know that he now needs a full-blown D interpreter to determine if some method is virtual or not. ;-)
> 
> An interpreter is required anyway.

and the idea is still bad.

For final, override, abstract, and synchronized attributes, I'm trying to relax the limitation in:

https://issues.dlang.org/show_bug.cgi?id=2091 https://github.com/D-Programming-Language/dmd/pull/4714

Kenji Hara

2015-06-03 13:47 GMT+09:00 ketmar via Digitalmars-d < digitalmars-d@puremagic.com>:

> On Wed, 03 Jun 2015 02:40:55 +0200, Artur Skawina via Digitalmars-d wrote:
>
> > On 06/03/15 01:41, ketmar via Digitalmars-d wrote:
> >> On Tue, 02 Jun 2015 18:49:09 +0200, Artur Skawina via Digitalmars-d wrote:
> >>
> >>> On 06/02/15 14:21, ketmar via Digitalmars-d wrote:
> >>>> this opens a can of worms. should this be accepted too:
> >>>>   enum doItFinal = false;
> >>>>   final(doItFinal)
> >>>> ?
> >>>>
> >>>> or even
> >>>>   final(someFunnyTemplate!(with_, args, andOtherTemplate!"too"))
> >>>> ?
> >
> >>> Of course.
> >>
> >> this is bad. it smells. it adds almost nothing in terms of uniformity. and i'm sure that Hackerpilot will be happy to know that he now needs a full-blown D interpreter to determine if some method is virtual or not. ;-)
> >
> > An interpreter is required anyway.
>
> and the idea is still bad.

If this DIP will be accepted, please make it work for "!shared" as well. I don't know whether any of you has experienced though, in some cases, cast() doesn't remove shared attribute at all, and I need to write half the screen, name of same class again.

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 need to iron out what happens with attributes like @safe/@trusted/@system or public/protected/package/private. Simply turning them on and off doesn't really work.

Regardless, I think that attribute(boolean expression) is the clear winner, because it's for more flexible. Without the ability to provide a boolean expression, some code will be forced to use compile-time introspection to determine which attributes are enabled and then enable or disable them as appropriate in different static if branches. That sort of case is really only going to pop up in generic code, but once you start turning attributes on and off, I fully expect that it will come up, in which case, a syntax such as !final won't work very well.

Also, Andrei has expressed interest in the attribute(boolean expression) syntax in the past, so that syntax has at least some support from him.

- Jonathan M Davis

On 6/3/15 2:19 PM, Jonathan M Davis wrote:
> Regardless, I think that attribute(boolean expression) is the clear
> winner, because it's for more flexible.

Yes please. -- Andrei

On 2015-06-02 12:29, Daniel Kozak wrote:
> I am working on dip which will try to addressed negation of attributes
> issue.
> http://wiki.dlang.org/DIP79

What happens if you use this syntax for a UDA, compile time error?

-- 
/Jacob Carlborg