July 14

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

>

Except when they are attributes — when applied to member functions.

No, then they are still type constructors. This:

struct S {
    void f() const {

    }
}

Is roughly equal to this:

void f(ref const S this) {

}
>

It makes no sense that const int variable is a constant integer while const int function() is a constant member function of some struct or class that returns non-constant integer.

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.

July 14

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

>

Two improvements to the grammar:

  1. Don't repeat the spec, use ... to signify a copy
  2. Use diff syntax for syntax highlighting

Note: there is already a tool for upgrading D code, DFix https://github.com/dlang-community/dfix

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

Thanks!

July 14

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

>

On Wednesday, 14 July 2021 at 15:54:06 UTC, user1234 wrote:

>

I'm worried not to see @const and @inout.

Those are type constructors, not attributes.

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

July 14

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

>

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

>

On Wednesday, 14 July 2021 at 15:54:06 UTC, user1234 wrote:

>

I'm worried not to see @const and @inout.

Those are type constructors, not attributes.

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

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.

July 15
On 15/07/2021 4:19 AM, Dennis wrote:
> On Wednesday, 14 July 2021 at 16:02:01 UTC, Andrea Fontana wrote:
>> It would be nice to have # for attr and @ for uda (or viceversa).
> 
> That conflicts with #line directives.

It doesn't.

#line checks for the identifier line as part of the lexer, and language defined attributes do not include line. So no conflicts :)
July 15

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

>

On 15/07/2021 4:19 AM, Dennis wrote:

>

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

>

It would be nice to have # for attr and @ for uda (or viceversa).

That conflicts with #line directives.

It doesn't.

#line checks for the identifier line as part of the lexer, and language defined attributes do not include line. So no conflicts :)

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?

July 16
On 16/07/2021 7:26 AM, Rune Morling wrote:
> 
> Is e.g. `@+myuda`, `@-myuda` or `@_myuda` legal?

_ may be in an identifier, so that one is 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?

Nah.

The moment we start changing rules around what an identifier means, that's symbol lookup. We really don't want to add more special cases there.
July 16

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

>

On Wednesday, 14 July 2021 at 15:54:06 UTC, user1234 wrote:

> >

Comments very welcome.

I don't like that @attr is colliding with UDA.
It would be nice to have # for attr and @ for uda (or viceversa).

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.

July 16

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

>

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

>

On Wednesday, 14 July 2021 at 15:54:06 UTC, user1234 wrote:

> >

Comments very welcome.

I don't like that @attr is colliding with UDA.
It would be nice to have # for attr and @ for uda (or viceversa).

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.

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
July 16

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

>

Hi All,
...
Comments very welcome.

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.

1 2 3 4