On Wednesday, 14 July 2021 at 16:55:30 UTC, Ogi wrote:

No, then they are still type constructors. This:

struct S {
    void f() const {

    }
}

Is roughly equal to this:

void f(ref const S this) {

}

return, scope, const, inout, immutable, shared outside the parameter list all apply to the implicit this parameter. The syntax is confusing, but there are multiple solutions. Adding @ variants for all type constructors is one of them, but that doesn't make it relevant to a DIP about function attributes.

On Wednesday, 14 July 2021 at 15:05:28 UTC, rikki cattermole wrote:

Both suggestions have been implemented in the latest version of the draft.

Thanks!

On Wednesday, 14 July 2021 at 16:18:21 UTC, Dennis wrote:

I reffered about the attribute form of const, e.g we would have

struct S
{
    void v(T)(const T t) @const {}
}

and very obviously the typector and param storage class would continue to use the keyword, i.e no deprecation for those

On Wednesday, 14 July 2021 at 17:45:34 UTC, user1234 wrote:

I didn't know the spec considers them attributes, I stand corrected. I still think it's a separate proposal though, since this DIP is about consistency among function attributes, not the confusing syntax of member functions with type attributes.

On Thursday, 15 July 2021 at 00:59:28 UTC, rikki cattermole wrote:

Is e.g. @+myuda, @-myuda or @_myuda legal?

As long as you can decorate with a consistent extra single character, wouldn't it be entirely possible (and perhaps even advantageous?) to use a commonly accepted best practice/idiom in order to distinguish user-defined attributes from compiler-defined attributes without needing to change the grammar?

On Wednesday, 14 July 2021 at 16:02:01 UTC, Andrea Fontana wrote:

I would rather have seen built-in attributes having no prefix ex. just safe, nogc etc.

Basically the opposite of making the rest of the attributes having @ too.

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

Making them have @ prefix would allow to make them a simple uda defined in druntime, which the compiler then would check for them and apply extra requirements over them.
Imho, this would actually simplify compiler code.

• Alexandru

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

What about making those attributes not just prefixed with @, but fully fledged UDA?
From the point of view of compile time code this would remove the necessity in strange syntax for is expression to get them. You'd just fetch them as any other uda.
Also this will allow us to extend these attributes with fields!
Say for example: @safe(disabled.yes)
Older compiler would just ignore this, but newer could take hints and other additional info defined on these udas for better optimization, or improved checks, or just for informational purposes.
Another example: @deprecated("See xxx for this functionality")

Best regards,
Alexandru.