In yesterday’s presentation by <@U2E974ELT> regard...
# language-proposals
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 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 🙏 .
👍 2
From what I understood, the
examples suggested an alternative meaning to
, not the annotation one. Defining
decorator fun foo
@foo fun other()
which would be a syntax to "apply" the decorator. Unfortunately, it's ambiguous with the annotation syntax.
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
and decorator names starting with a lowercase letter, like
👍 3