A modern programming language that makes developers happier.

kotlinlang

Can we get easier access to the decomposition of functional types? I recently had to implement this and it seemed like it could be part of the official api library. Or maybe something like this isn't officially added for some reason that I'm missing?
You can see my solution in the thread

<https://github.com/Recrafter/lapis/blob/main/src/main/kotlin/io/github/recrafter/lapis/common/KSFunctionType.kt|https://github.com/Recrafter/lapis/blob/main/src/main/kotlin/io/github/recrafter/lapis/common/KSFunctionType.kt> 

FYI: Skipped ⁠suspend⁠ and context parameters for now as out-of-scope for my needs, but the structure easily allows adding them via additional argument index handling

Hi, thanks for the suggestion. It looks to me like you reconstructing some of the functionality from `KSFunctionDeclaration` which can be obtained from the `KSType`. Is that correctly understood or how are you using `KSFunctionType`? Cheers

<@U0ACBLVGERX> I use `KSFunctionType` to parse a functional type (`A.(p1: Int) -> Unit`) into its constituent parts. In my KSP plugin syntax/design, the developer describes a target bytecode scheme similar to this:
```@Method<(graphics: GuiGraphicsExtractor, x: Int, y: Int, isSelected: Boolean, index: Int) -> Unit>
interface extractRenderState```
The thing is that `KSType` only has the `isFunctionType` flag, but it has no ability to extract the internal structure.
So, `KSFunctionDeclaration` is not suitable here, since it is a function and not a function _type_.

Under the hood, the functional type is converted into a Function(0-22/N) generic, and in order not to lose information about context parameters, the presence of a receiver, and parameter names, the Kotlin compiler inserts the annotations `@ContextFunctionTypeParams`, `@ExtensionFunctionType` and `@ParameterName` , respectively.
It seemed to me that this information could be extracted at the level of KSP itself and an interface could be provided for this so that other developers wouldn't have to understand these subtleties and not have to mess with the compiler :slightly_smiling_face:

Ah I see what you mean. Feel free to open an issue on GitHub, then we can discuss further there. It's probably not something that will be prioritized right now but it'd be helpful to have a discussion around the design or at least have it as a feature request.

<@U0ACBLVGERX> Ok, I'll draft a GitHub issue with the proposal and design details later this week. Thanks for the guidance!