When a @foo is considered an attribute and when it's not

[stefanos82]

I'm using Vim editor and have noticed some keywords are not highlighted which I plan to fix and push a PR.

As the title says, when a @foo keyword is considered an attribute and when it's not?

I know we use the same @ operator inside the Doc contracts which makes the whole situation more confusing...

If we open the module lib/std/net/url.c3, we can see unhighlighted keywords, such as @pool(), @ok(a_keyword_in_here), @stack_mem(128; Allocator smem), and of course, the most confusing part can be found in fn void UrlQueryValues.free(&self) which looks like this:

fn void UrlQueryValues.free(&self)
{
	self.map.@each(;String key, UrlQueryValueList values)
	{
		foreach (value: values) value.free(self.allocator);
		values.free();
	};
	self.map.free();

	foreach (&key: self.key_order) key.free(self.allocator);
	self.key_order.free();
}

The self.map.@each()...what is supposed to mean here?!

Can anyone enlighten me so I know which keywords need to get set as attributes in Vim editor so I can PR as soon as possible?

[EroMrinin134]

There is only a few built-in attributes, however, user-defined ones are starts with capital letter: @MyAtrr.
@each is a macro: macros that uses #expr are prefixed with @.

[stefanos82]

Allow me to express my concern about this current state of syntax.

On one side, we want to avoid using existing operators to do multiple things, such as the case of the ternary operator ?: that we had to introduce new syntax for compile-time process which now we have ???: that looks like a typo on a user's behalf or the user's keyword got stuck and entered multiple question marks 😕 , but at the same time we use existing operators such as the @ to do different things under specific circumstances.

Isn't there a way to get rid off of this unnecessary fuss to avoid future nightmares that could lead to further language and syntax complexity?

[stefanos82]

Another thing that I've just thought was a naive way to disambiguate the usage of @ operator / token / character or what other name it may have.

Would it be wrong to replace the macro syntax to match that of Rust's?

In other words, this example

fn void UrlQueryValues.free(&self)
{
	self.map.@each(;String key, UrlQueryValueList values)
	{
		foreach (value: values) value.free(self.allocator);
		values.free();
	};
	self.map.free();

	foreach (&key: self.key_order) key.free(self.allocator);
	self.key_order.free();
}

would become

fn void UrlQueryValues.free(&self)
{
	self.map.each!(;String key, UrlQueryValueList values)
	{
		foreach (value: values) value.free(self.allocator);
		values.free();
	};
	self.map.free();

	foreach (&key: self.key_order) key.free(self.allocator);
	self.key_order.free();
}

I think this would improve readability by orders of magnitude!

[Book-reader]

@foo is considered an attribute if it is:

1. after the closing parens of a function declaration (fn void foo() @inline), this could probably be considered the same as 2.
2. after the name of a declaration (int x @foo = 1, typedef Foo @structlike = Bar, struct Foo @packed, module foo @test)
3. after a type name (int[<4>] @simd)
4. after the closing paren of a switch (switch (foo) @jump)

there is a little more nuance--they're also after generic params in a generic declaration for example--but they can only appear in places that macros can absolutely never appear.
I will agree that it's difficult to write a highlighter for them though, in the end I just hardcoded the builtin attributes in the kakoune highlighter because it's extremely difficuly to differentiate them with a regex.

[stefanos82]

...imagine the confusion of a newcomer to C3 that has to know this in advance so he/she can use the language the right way!