Proposal for typed attributes

[danieldaeschle]

This would be super useful for our vweb framework which has some attributes. Using this technique, we could remove compiler magic for the vweb module and make a more generic solution.

Requirements

1. It should be able to define methods on it. Those methods can be looked up at compile time then and be called.
2. It should be able to contain fields/parameters.
3. It should not be able to pass an attribute as a type parameter in function arguments nor cast or instantiate something.
4. It should not have any field visibility like pub or mut

A: struct attribute - attribute

an attribute struct shouldn't have struct embedding, pub mut, be initialized nor be used as a type parameter.
An example would look like:

enum HttpMethod { get post put delete patch }

@[attribute]
struct Route {
    path       string
    method HttpMethod
}

// .get looks a little bit weird. we could use also a string with `'GET'` or something. but it's only an example here.
@[Route{'/index', .get}] // or even [Route{path: '/index', method: .get}]
fn index() {}

B: attribute keyword

This would introduce another keyword but would be good as well is:

enum HttpMethod { get post put delete patch }

attribute Route(path string, method HttpMethod)

// .get looks a little bit weird. we could use also a string with `'GET'` or something. but it's only an example here.
@[Route('/index', .get)] // or even [Route(path: '/index', method: .get)]
fn index() {}

Obviously, the last proposal would introduce more complexity to the compiler which could also slow it down. But the syntax will be shorter and structs wouldn't be used for different things.

Using attributes

Either attribute using is always like this: @[Route('/index', .get)].
Or if we decide to use a casted form of a struct, we could use the syntax @[Route{'/index', .get}]

[IngwiePhoenix]

Since attributes kinda remind me of TypeScript's decorators and their proposal in ES6, why not borrow from them outright and change it a little?

// Most identifier/keyowrd names are short - so I decided to stick with it.
attr fn(f fn()) Route(path string, method HttpMethod) {
  router.register(
    path: path
    method: method
    callback: f
  )
}

Treading attribute functions like they had a context or were a method might allow to specify where and when attributes would be allowed - but that is probably way over the top.

Also if I recall correctly, in Rust, you have to specifically import macros as well to use them. With attributes, it should probably be the same to be on the save side to make sure two attributes from different modules would not clash.

import webframework
import attrs webframework // explicitly import the webframework attributes.

[danieldaeschle]

@IngwiePhoenix Good idea. Python also has decorators. But decorators are not the same as attributes. Take a look a t C# attributes to see something similar.
I'm thinking the whole day about how we could implement them and what they need. Will update this soon.

[Delta456]

Wouldn't this make the language bigger?

[danieldaeschle]

Alex gaves his ok for it. It just needs a solid specfication.

[spaceface777]

You can already implement custom attributes via V's compile-time $for/$if, although these are currently very limited to very basic things. I'd rather have more powerful compile-time features (e.g. calling functions at compile-time), rather than introducing new language features.

[danieldaeschle]

@spaceface777 I will extend this. I forgot to add the definition that those custom attributes are typed.

[danieldaeschle]

I see some flaws if we have untyped attributes:

1. The compiler should catch user errors
   if one would do this:

[get]
['/myroute']
[/route-without-string]
[inline]
pub fn (mut app App) my_route() Result {
    return app.text('My Route')
}

this results in: having the follwong routes: /nline, /myroute, /route-without-string
If we would have typed attributes this can be prevented by the compiler.

2. more possibilities with attributes (e. g. multiple parameters)

[spaceface777]

1. I don't think that attributes handled by the compiler (e.g. inline, export:, etc.) should be included in FunctionData.attrs, or there should at least be a way to differentiate them from custom attributes (maybe make attrs have a custom: bool field?)

Also, functionally, what's the difference between an attribute with a string (['/myroute']), and an attribute with an ident ([/route-without-string])? From a user's perspective, it looks as if they'd work the same, so maybe one syntax could be deprecated, or the difference should be documented otherwise.

Type checking could still be done by the user at compile-time, if we had (for example) a compile-time $error() function that would produce custom compiler errors, but automatic checking by the compiler would be nice.

[danieldaeschle]

I see an advantage to define inline and export: as typed attributes as well. It would be in the code and every user can see it. It can also be documented in the code which will be in vdoc then.

Non-typed attributes wouldn't give the ability to have middlewares in attributes:

[attribute]
struct Authorize {}

pub fn (a Authorize) before_request() {
    // some jwt stuff and return 401 if not authorized
}

[Route('/settings', .get)]
[Authorize]
pub fn (mut app App) settings() {
    // ...
}

It would be the same as C# has. Very powerful.

[danieldaeschle]

Also, functionally, what's the difference between an attribute with a string (['/myroute']), and an attribute with an ident ([/route-without-string])? From a user's perspective, it looks as if they'd work the same, so maybe one syntax could be deprecated, or the difference should be documented otherwise.

It's a bug, not a different functionality. It's just not easy to catch all cases which the user can do wrong. With typed attributes compile time check would be easier.

[spaceface777]

yeah, ok, I see your point and agree :)

[dumblob]

Well, do I understand it correctly, that an attribute [...] (i.e. anything between square brackets) would be arbitrary standard V code? That'd be awesome as there'd be no need for the programmer to learn any new syntax, everything would be type checked, it'd be by definition extensible, there'd be no need for a different parser, no need for a different checker, etc.

[tomByrer]

I don't really like the [square bracket] notation, sorry. I don't plan to learn C#, where I guess many got used to it. Makes it seem too 'magical', & I've been programed to see everything in a square bracket as a list.

I'd prefer more plain text notation like IngwiePhoenix's idea.

The idea of 'attributes' would make things like vweb much easier to program for sure. Maybe make it a DSL for vweb, & see if you like it enough for all of V?

[danieldaeschle]

@larpon why close and reopen? :D

@tomByrer Yeah, it's your personal preference. But does it matter if it's [] or @ like in Java? It's really a minor thing in this case.

This issue is more about having typed attributes rather than chaning the attribute feature. What IngwiePhoenix showed are not attributes. That are decorators which is a different technologie.

[larpon]

@danieldaeschle , lol - sorry I have no idea what happened 😄

[IngwiePhoenix]

Yes - and no. Let's use __attribute__(visibility("default")) for example. It changes the symbol visibility on a function in C. It is a attribute, but also a decorator in the sense that it modifies the function - at least in a way.

Say the [extern:] attribute was formalized as a function, it'd probably look something like this:

attr fn(mut f &FunctionData) extern(name string) {
  // ...
}

f would be the function associated with the [extern:] attribute. But, this definition right there also goes hand in hand with how a TypeScript or JavaScript decorator would work; it's basically just a function receiving another to fulfill a purpose. Be it to change visibility - or as it is used in places like the TypeScript framework Nest Framework, to configure routing.

They are not exactly the same, but basically work on even grounds. Just that in C __attribute__(...) can not be user-defined and is predefined by the C compiler itself, whilst decorators can be user defined.

But if you use @ or [] is just a syntactic discussion - on a functionallity level, an attribute as known from C and a decorator from JS/TS are quite close.

[danieldaeschle]

Attributes in V are more like Annoations in Java. They have no functionality on their own.

[danieldaeschle]

Yeah, I know everything you mentioned. My understanding is that V has no decorators like Python or TypeScript but attributes like C# which are handled at compiletime which is faster.

[IngwiePhoenix]

Yeah, right now all attributes are handled at compile time and in the generator - cgen, for instance.

Technically, if the comptime feature was extended to define compiletile functions, attributes defined per library wouldn't be far off.

[danieldaeschle]

We won't use compile time functions for this case. This doesn't work. Compile time function don't have access to struct fields.

[tomByrer]

it's your personal preference

That's true! I'm shopping for a language with few 'magic characters'; faster to learn & teach IMHO, & I don't have to think twice if [] = array or not.
But I understand some would prefer code to be more left-aligned as possible.

I do like @ better, since my mind I read it as at, so it feels more like a flag.

[igotfr]

I think it is related: #11903

[IngwiePhoenix]

So... Whatever became of this proposal? I want to write a web app with V and would love to use attributes to denote routes and possibly other things. Any news?

[danieldaeschle]

Unfortunately not

[Apocryphon-X]

Hello, is there anything new about this? Is this discarded or will it be implemented in the future? 🤔

[danieldaeschle]

It's decided to implement this in future, but it's not decided how and when.

[kobi2187]

I don't like this feature. I never liked it in C# either. This is a hidden code generation and not obvious to the casual code reader what it does. The language is less readable in terms of understanding what is there, it is not translatable in obvious ways, for example, in porting code.
all in all, there are other ways to accomplish these things without resorting to macro style attributes. sorry for the rant. I think v looks really elegant and has very good design choices. It is also important to know what not to include, what would make the language farther from its original vision.

[dmitryuck]

suggesting a syntax like this

@my_simple_attribute

@my_attribute_with_data(param1 any, param2 any)

@my_func_attribute(path string, method HttpMethod) {
    // executes when the instance is created with an attribute
    // a target object to which attribute is applied can be accessible through it parameter for ex: it.target
}

@[my_simple_attribute; my_attribute_with_data(123, "Hello"); my_func_attribute('/index', .get)]
fn index() {...}

function attribute call automatically when an instance with an attribute is created, an attribute object can be accessible in a function
attribute with data can pass some parameters to it's target

[hholst80]

I don't like this feature. I never liked it in C# either. This is a hidden code generation and not obvious to the casual code reader what it does.

Completely agree. I will use it if it's there but I would prefer if I did not have to learn another thing. It is more flexible to register the callbacks programmatically in any fashion you'd like than to be locked down to a special purpose typing. In C# this is a complete clusterfuck too where multi-line decorators is the norm, so I do not think looking at C# as best practice is good. At best Python and flask/Django could serve as a prototype, but even there, it's convenient boilerplate for hello-world sized services. It is not needed unless there is a number of other use cases from say Python that V also want to cater to.