Attributes

[nrc]

Design doc for attributes (@settings, etc).

[jtran]

Instead of inner and outer, could we call them item attributes and scope attributes, respectively? Seems clearer.

[nrc]

I like item attr, but I find 'scope' a bit ambiguous. I was hoping to not use either terminology in user-facing docs, just named/unnamed and explain how they apply

[jtran]

The lack of identifier after the @ for inner attributes makes it awkward to use many, unrelated attributes for an item. Instead of them looking like function calls, they would need to be differentiated by keyword arguments. An example I'm thinking about would be in Rust #[derive(Clone, Serialize)] and #[serde(rename_all = "camelCase")] on a struct. How would you do the equivalent here?

@(derive = [Clone, Serialize], serde = { rename_all = camelCase })

I know KCL is very different from Rust, so the specifics don't apply. But in most languages that have item attributes, it's common to want to apply multiple, unrelated attributes to the same declaration.

I think I'd prefer a different token or tokens the way Rust does it with # vs. #!.

[nrc]

I was thinking like:

@(derive = [Clone, Serialize])
@(serde = { rename_all = camelCase })

So, the logic here is that the name after the @ for inner attrs is showing the target of the attribute, whereas with outer attrs the target is always the following item

[jtran]

I think I'd choose attributes too. It's pretty arbitrary, as long as we stick with one. The only theme I've seen maybe hinted at is that annotations have no runtime effect by default. But it's all just metadata.

[jtran]

Can we remove the @? I thought someone said that we needed a way to distinguish between a regular function and one that has a "self" parameter.

An alternative is how Python does it with a separator between positional and named parameters. I don't particularly like this, but it's optimized so that in the common case, the separator is rarely needed at all. For KCL, it would potentially allow us to free up the token.

If we need to keep it, couldn't we use basically any other token?

@outer

@!inner
fn foo(!positional: Plane, named: string): Sketch {}

// Attribute on the positional parameter.
fn foo(@!inner !positional: Plane, named: string): Sketch {}

[nrc]

"I thought someone said that we needed a way to distinguish between a regular function and one that has a "self" parameter." - hmm, yeah

"If we need to keep it, couldn't we use basically any other token?" - yes