In yesterday’s presentation by <@U2E974ELT> regard...

# language-proposals

[raulraja]

In yesterday’s presentation by @elizarov regarding the potential future features of Kotlin @with was mentioned. We were exploring changing arrow meta @Given to this proposal but we quickly encountered as so have others the limitation with generic type args as in @with<ComparableA> or similar where A is in the function it decorates as a generic arg.

We found this issue where this is being discussed https://youtrack.jetbrains.com/issue/KT-42435 by @etolstoy as well.

Has there been any thoughts as to how to deal with these cases or does anyone have any ideas as to how we can enable these additional receiver types that are generic over annotations that need to be concrete on their type? Also interested in thoughts about how to support multiple type args since `@with(Rec1, Rec2…). Thanks for any ideas 🙏 .

@with

[raulraja]

https://youtrack.jetbrains.com/issue/KT-42435

[edrd]

From what I understood, the @withTransaction and @with examples suggested an alternative meaning to @, not the annotation one. Defining decorator fun foo allows @foo fun other() which would be a syntax to "apply" the decorator. Unfortunately, it's ambiguous with the annotation syntax.

[elizarov]

Indeed, we overload @ to mean both a use of an annotation and an application of a decorator. However, our vision is that a naming convention will help to see through ambiguities in practice. You'll usually have annotation names starting with an uppercase letter, like @Deprecated and decorator names starting with a lowercase letter, like @with.