Has there been any discussion about adding a `comp...

# language-proposals

[Ben Woodworth]

Has there been any discussion about adding a componentN operator that takes parameters?
For `List`s and `Array`s, the standard library has to define component1-5 functions, but a component operator with a positional argument could be used if it existed:

component.kt

[elizarov]

How would you use it? Do you have a real-life use-case?

[Ben Woodworth]

I've used destructuring for main() args, and had to define my own component6+ functions. I've also implemented simple pattern matching, and added a dozen or so component functions for a match container so a lambda argument could be destructured with the matches.

In the standard library, Arrays and Lists have 5 component functions each, and the regex MatchResult class has 10 defined. They all do the same thing so it's a bit redundant, especially when one catch-all component function could do.

Here's an example of something similar to what I'm doing right now with text processing:

Untitled

[elizarov]

Thanks 👉 https://youtrack.jetbrains.com/issue/KT-17147

[eduardog3000]

Name based destructuring like in JS would be nice. Is there any discussion going on about that?

[Ben Woodworth]

I was also thinking about that. Something like this could be possible:

Untitled

[ilya.gorbunov]

@Ben Woodworth By the way, you can use MatchResult.Destructured as a type for captures instead of `List<String>`: https://github.com/JetBrains/kotlin/blob/1.3.60/libraries/stdlib/src/kotlin/text/regex/MatchResult.kt#L96

[elizarov]

@eduardog3000 We’ve discussed JS-style syntax for name-based destructuring and found it to be bad fit for an a type-safe laguage with an IDE, since when you start typing names of component your IDE does not yet know what are you trying to descruct and cannot provide you with an appropriate auto-completion options.

[Leon K]

@elizarov IDE-autocompletion should imo not be the deciding factor for language-features, as you only write your code once, but read it many times. if desctructuring makes it more readable, the "writability" should not be the deciding factor.