On Friday, 16 July 2021 at 09:06:26 UTC, Alexandru Ermicioi wrote:

I absolutely agree! I started writing a longer post on exactly this topic, but you beat me to it :P

On Friday, 16 July 2021 at 09:06:26 UTC, Alexandru Ermicioi wrote:

And make attributes symbols:

template Pure(bool con){
	import std.meta : AliasSeq;

	static if(con)
		alias Pure = pure;     //this is not valid
	else
		alias Pure = AliasSeq!();	
}

//conditional atributes:

void foo()@(Pure!true){   //expand to `pure`

}

void bar()@(Pure!false){   //expand to `()`

}

On Friday, 16 July 2021 at 10:17:39 UTC, vit wrote:

If they are UDA, then they are symbols.
I.e in object.d you'd have struct defs for each lang defined attribute:

struct safe {...}
struct nogc {...}
struct deprecated {...}

This consequently means that you can employ them in a template like in your example, or ctfe function that is put as an annotation:

void textedDeprecate(T...)(T args) {
  return deprecated(text(args));
}

@textedDeprecate("this is obsolete since ", 1.0)
struct Obsolete {
}

On Friday, 16 July 2021 at 09:06:26 UTC, Alexandru Ermicioi wrote:

To add one more strong point on making them uda:

Suppose that you have a collection interface Collection(T). In order to make it portable and usable in safe pure or nogc code, the methods in collection should infer the properties of stored entities. This is not possible at the moment since you can't define these attributes based on a condition. However, if you make them UDA this means that you can create templates that check the capabilities of the stored entities and alias itself to the supported tuple of features, say Foo is safe but nogc, then instantiation of collection will become @safe Collection!Foo, while for nogc but unsafe Noo struct it will become @nogc Collection!Noo.

Regards,
Alexandru.

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

I just noticed there is an issue for this:
https://issues.dlang.org/show_bug.cgi?id=13388

And a discussion:
https://forum.dlang.org/post/rtwbtxigfeupvykpbamh@forum.dlang.org

And a PR that got merged:
https://github.com/dlang/dmd/pull/4341

But reverted because there was no consensus in the discussion yet:
https://github.com/dlang/dmd/pull/4349

On Wednesday, 14 July 2021 at 15:01:05 UTC, Rune Morling wrote:

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.

On Friday, 16 July 2021 at 06:47:57 UTC, bauss wrote:

+10.447464

More syntax was fine when the attributes were new, but it seems to me what is needed would be more "normalcy": safe, trusted, nogc
If you're calling your variable safe or nogc, then well they are now keywords: choose proper names.

On Saturday, 17 July 2021 at 10:51:20 UTC, Dennis wrote:

Thank you for the investigation and for listing the prior discussions.

I've read all of it and the most pertinent summary of the situation I could find was this:

In other words, unless I/we can come up with an "algorithm" for deciding when something should be an @-attribute, the DIP I've proposed has little merit in that it's basically just proposing that we shuffle attributes around on a whim.

Personally, I'm currently leaning towards something that describes how a keyword/attribute changes the amount of checks that the compiler makes so that it's akin to switching to a different "mode" of compilation with attendant extra/fewer checks/limits on functions.

On Sunday, 18 July 2021 at 09:50:30 UTC, Nick Treleaven wrote:

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

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 functionality?

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?

On Wednesday, 21 July 2021 at 20:00:32 UTC, Rune Morling wrote:

Here's my take.

D's attributes can be divided, conceptually, into a few different "groups" of related attributes. Some examples are:

1. The Type Constructor Group: const, immutable, inout, and shared.
2. The Inheritance Group: final, override, and abstract.
3. The Visibility Group: public, private, protected, package, and export.
4. The Function Attribute Group: pure, nothrow, @nogc, @safe, @system, @trusted, @property, and @live.

...and so on.

The rule I propose is that within a single group, use of @ should be consistent--either all of the attributes should use it, or none of them should.

Of course this invites some debate as to where exactly one ought to draw the group boundaries (e.g., should @property be counted as part of the function attribute group, or is it a separate thing?). But it is at least a step forward from the current discussion, which does not even acknowledge that these groups exist in the first place.