Custom attributes syntax discussion

[medvednikov]

For general ideas:

C#

[MyCustomAttribute("ExampleClass", Version = 1)]

Python

def my_custom_decorator(func):
    def wrapper(*args, **kwargs):
        print(f"Calling function: {func.__name__}")
        return func(*args, **kwargs)
    return wrapper

@my_custom_decorator
def example_function():
    print("This is an example function.")

Swift

@propertyWrapper
struct Capitalized {
    private var value: String = ""
    var wrappedValue: String {
        get { value }
        set { value = newValue.capitalized }
    }
}

struct Example {
    @Capitalized var name: String
}

[JalonSolov]

I much prefer the simplicity of the C# version, although it should be expanded at least slightly.

For example, it would be good to be able to specify the number and type of arguments. I'm not sure what good versioning will do on an attribute, although it might be handy for future-proofing, in case we needed to change how the attribute worked, the number and type of arguments, etc.

[EmmaTheMartian]

I like the struct proposal seen here: #11732

Basically, something like this:

@[attribute]
struct SomeAttr {
// mut not allowed. in the original post, it was pub by default. However IMO we should not do that because we are using plain struts here. I would rather use existing syntax than changing it.
pub:
        name string
        age  int
}

@[SomeAttr{"Gandalf", 50000}]
fn something () { ... }

I also think we should pull from Java a little bit by giving attributes a list of which things they can be applied to, maybe something like this:

@[attribute: 'fn'; attribute: 'struct']
struct MyAttribute { ... }

// This would produce a compiler error:
struct Hello {
  name string @[MyAttribute{}]
}

Edit: For attribute that are hard coded (inline, extern, attribute, etc), we can probably leave them as is. Structs mandate CamelCase and all existing attributes are lower_snake_case, giving a clear distinction. Migrating fully to one single syntax would certainly be nicer in my opinion, but that is a topic for later I think.

[danieldaeschle]

Thanks for bringing up my old issue :)

[islonely]

I love this! It would be awesome to see something like this supported in V.

[Krotki]

I also had similar idea reading first post.

Additional benefit it looks and behaves similar to Trailing struct literal arguments.

[Krotki]

It could also have some additional behavior defined on methods on such struct.

[medvednikov]

@EmmaTheMartian sounds good to me.

[jorgeluismireles]

An alternative is to borrow Go tags simple map syntax but combined with already form @[...]. Go code:

package main

import (
	"fmt"
	"reflect"
)

func main() {
	type S struct {
		F string `species:"gopher" color:"blue"`
	}

	s := S{}
	st := reflect.TypeOf(s)
	field := st.Field(0)
	fmt.Println(field.Tag.Get("color"), field.Tag.Get("species"))

}

Useful in json encoding and read by a reflection package. And very important to document the whole mechanism: https://pkg.go.dev/reflect#StructTag

[EmmaTheMartian]

Looks like just adding a string to the type/struct/fn (correct me if I'm wrong)
I'm not sure if I like that very much, it feels like it would get tedious very fast.

[JalonSolov]

V already uses `` to mean rune not string, so that would have to change... but if it changed to ' around the attribute, how could you tell is wasn't just a typo... that you didn't mean

	F string = 'species:"gopher" color:"blue"'

[JalonSolov]

There was a suggestion to change attributes to something like @attr(arg), which would be slightly shorter than @[attr: arg]. It would also make it simpler to have multiple args, as in @attr(arg1, arg2, ...). If there are no arguments, it could be just @attr, but that might get confusing... may be better to have @attr().

[jorgeluismireles]

I didn't mean to use `` but something like:
@[camel_one:'data,omitempty' camel_two:'false']

[Avey777]

Has this started yet? What is the final grammar?

[JalonSolov]

It it was decided, the discussion would be closed.