@clientName shouldn't carry over

[timotheeguerin]

Similar to discussion we just had for @friendlyName, @clietnName shouldn't carry over model is

Playground

[tadelesh]

From TypeSpec doc: https://typespec.io/docs/language-basics/models#is, is will carry over the decorators, Does it mean it is done by compile?

[timotheeguerin]

Yeah by design decorator get carried over by the compiler and we don't have a way to opt out of that behavior but there is other way to make it behave the same.

If you check the target of the decorator node and compare to the decorator node parent and make sure they match then it should only run in the case where client name was defined there

[tadelesh]

Yeah by design decorator get carried over by the compiler and we don't have a way to opt out of that behavior but there is other way to make it behave the same.

If you check the target of the decorator node and compare to the decorator node parent and make sure they match then it should only run in the case where client name was defined there

Will compiler provide an API to distinguish if a decorator is a direct decorator? Have @friendlyName in core resolve such problem? I suppose it should be done in the decorator set function.

[timotheeguerin]

yes @friendlyName has the same problem but we can't change it as it will be breaking(it is one of the major issue with @friendlyName and why we tried to get rid of it), @clientName has the opportunity before its too late.

And no there will not be a compiler api to do the workaround. There will be an api at some point to make decorator not carry over. The workaround shouldn't be too hard to write.

if((context.decoratorTarget as DecoratorNode).parent !== target.node) {
return;
}

[tadelesh]

@timotheeguerin do you know how to deal with augment decorator? I could not find a way to get the exact node for the referred node.

[timotheeguerin]

Hhm yeah didn’t think of that…

this one might be more tricky and maybe mean we need to prioritize designing a better solution in the compiler.

what you can do is check the node of the augment decorator then see what it is the first argument and check the reference symbol to get the nodr

[tadelesh]

When I tried to resolveTypeReference for a union variant, I got infinite loop. See code in this PR.

@service({})
namespace N {
  union TestUnion{
    "A",
    "B": "B_v",
    string
  }
  op x(body: TestUnion): void;
}

namespace Customizations;

@@clientName(N.TestUnion.B, "BRename");

[timotheeguerin]

So I think this issue only matters for model and operations names so maybe could limit to that for now.