RFC: DIP draft for "Compiler-defined Attribute Consistency"

Rune Morling ermo at serpentos.com
Wed Jul 21 20:13:16 UTC 2021

On Sunday, 18 July 2021 at 09:50:30 UTC, Nick Treleaven wrote:
> On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:
>> The current DIP draft can be found 
>> [here](https://github.com/ermo/DIPs/blob/compiler-defined-attribute-consistency/DIPs/1NNN-RM.md).
> I support using built-in @attributes when they only affect 
> functions, not parameters, variables or fields. This would mean 
> only a few minor additions to increase consistency. For this we 
> need to add @override, @abstract, @final ('@final class' only 
> affects a class's methods, not field members) to the DIP.

In keeping with my last post, what is your proposed reasoning for 
using @override, @abstract and @final (= making them 

As I see it, @nogc, @nothrow, @pure and @safe all define that 
something out of the ordinary or special is happening on a 
language/compiler "meta-level" rather than being directly 
associated with/derived from with class/type hierarchy 

My take:

- abstract says something about the type of a class/function 
(part of the OOP hierarchy)
- final says that a function in a class cannot be overridden 
(part of the OOP hierarchy)
- override says that a function in a class is being overridden 
(part of the OOP hierarchy)

Can you help me understand what I might be missing here?

More information about the Digitalmars-d mailing list