new syntax for attributes

[StunxFS]

Describe the feature

Currently, attributes are simply a label that can accept a simple value: atribute: value, but this syntax is somewhat limited. My idea is that instead of using a simple label that can accept a simple value, we use a syntax similar to that for function calls: atribute(argument).

Use Case

The idea came up while reviewing PR #25480, a possible solution would be to use this new syntax to unify the deprecated attribute:

@[deprecated('use ultimate_fn instead', after: '2025-10-10')]
fn super_fn() {}

fn ultimate_fn() {}

Proposed Solution

This new attribute syntax could behave just like a function call, allowing positional arguments as well as named arguments.

@[unsafe]
@[deprecated]
@[deprecated('use new module instead')]
@[deprecated(msg: 'use new module instead', after: '2025-10-10')]

Attributes that do not take arguments may ignore ().

Also, the user (and even the compiler itself in the builtin module) could define attributes using the following syntax:

@[atribute]
fn deprecated(msg string, after string)

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Version used

latest

Environment details (OS name and version, etc.)

all

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-26184

[JalonSolov]

There was a suggestion in 2020 to change the whole attribute syntax to

@attribute()

instead of

@[attribute]

• basically, make it look like a function call, which could then have as many parameters as needed.

[gechandesu]

For now attribute is VAttribute for top-level symbols and just a []string for enum values and struct fields. IMO, attributes should be the same everywhere. However, turnung []string attrs to VAttribute would be a breaking change. VAttribute also needs to be significantly modified to make parameterization possible.

I prefer this syntax:

@[attribute]
@[attribute_a; attribute_b]
@[attribute(one: 1, two: 2)]
@[attribute(one: 1, two: 2); attribute2(hello: 'world')]
@[attribute('non-keyword argument')]

UDP: I think the current syntax for attributes with an argument looks clean and doesn't require a lot of extra characters (especially for struct fields/enums). I think this syntax should be retained for attributes that take a single argument.

@[attr1: val1; attr2: val2]

Attribute parameters must be optional.

Multiline ones also must be accepted:

@[
    deprecated(
        msg: 'use foo instead'
        after: '2026-01-01'
    )
    documentation(
        text: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed
do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex
ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate
velit esse cillum dolore eu fugiat nulla pariatur.'
    )
]

Rust attrubutes looks good for me https://doc.rust-lang.org/reference/attributes.html

I'm not sure whether attribute values ​​should have their own type or whether we can accept them all as strings. The string approach seems simpler. We could store them in a VAttribute object as map[string]string.

---

If we also talk about "custom attributes":

Attributes aren't decorators like in Python, so we could turn structures into attribute field descriptions. I have no idea how to implement this, but it could look something like this:

@[attribute] // Register struct as attribute schema for compiler
struct Documentation {
   text string
   ref  string
}

@[Documentation(text: 'foo bar')]
fn foo() {}

// or use {} to make them like struct initialization (but i prefer `()`):
@[Documentation{text: 'foo bar'}]
...

I also recall the discussion at #23445

[JalonSolov]

@[attribute('non-keyword argument')]

is just extra characters to type, when

@attribute('non-keyword argument')

will do the same job.

The only reason it changed from [] to @[] was due to parsing conflicts with array access syntax, but there are no conflicts with @attr().

[dy-tea]

I like this idea, it keeps the current boolean attributes concise but it improves the usage of attributes.
The custom attributes are interesting but I'm not sure what they would be used for (calling some function associated with an @[attribute] struct?).

[gechandesu]

The only reason it changed from [] to @[] was due to parsing conflicts with array access syntax, but there are no conflicts with @attr().

We can apply multiple attributes to a symbol. @[] helps group them. For top-level symbols attributes can be written on a new line:

@attr1()
@attr2()

but this won't work for structure and enum fields, which can also have more than one attribute.

struct Config {
    user_name string @[json: 'userName'; toml: 'user-name']
    // idk how achieve the same with @attr() syntax
}

[gechandesu]

The custom attributes are interesting but I'm not sure what they would be used for (calling some function associated with an @[attribute] struct?).

Currently, anyone can set an arbitrary attribute on a symbol, but it has to be parsed manually at compile time. A custom attribute will immediately produce a ready-made structure with fields. That is, instead of extracting values ​​from VAttribute, the compiler will return your MyAttr struct (marked by @[attribute]) instead of VAttribute. I guess.

[StunxFS]

I like the idea of ​​using the @attribute() syntax (similar to annotations in Java).
And yes, we could use the current attribute syntax to group several attributes on a single line, making it less verbose to use them in struct fields.

struct St {
    field1 int @[required; json(field_name: 'Field-1')]
}

@unsafe
fn modify_ptr(ptr &u8) {}

@export('printf')
fn printf_impl(fmt string, ...) {}

@[direct_array_access; inline(.never)]
fn tagged() {}

And regarding custom attributes, the idea is that the compiler can keep track of which attributes exist, and also know how many arguments are expected.

@attribute
fn deprecated(msg string, date string)

@deprecated('use us_fn() instead')
fn my_fn() {}

@deprecated('use us_fn() instead', '2020-01-09')
fn my_fn2() {}

@deprecated('use us_fn() instead', '2020-01-09', 'a') // ERROR
fn my_fn3() {}

[gideaoms]

The only reason it changed from [] to @[] was due to parsing conflicts with array access syntax, but there are no conflicts with @attr().

We can apply multiple attributes to a symbol. @[] helps group them. For top-level symbols attributes can be written on a new line:

@attr1()
@attr2()

but this won't work for structure and enum fields, which can also have more than one attribute.

struct Config {
user_name string @[json: 'userName'; toml: 'user-name']
// idk how achieve the same with @attr() syntax
}

struct Config {
    user_name string @json('userName') @toml('user-name')
}

[JalonSolov]

Or even

struct Config {
    user_name string @field_attrs(json: 'userName', toml: 'user-name', omitempty)
}