The results are in, and immutable data, collection literals, and SAM conversions are the most-requested features for Kotlin. One dev sounds off on the survey.
So, the survey results for Kotlin’s future features are in. Let’s talk about that.
First off, I’ d like to say that I’ m sad that I wasn’ t able to participate in this. It’s not that JetBrains stopped me, I just wasn’ t able to watch at the time.
Next, you should familiarize yourself with the different proposed features so you know what is being talked about.
I find it interesting the differences between the two sets of surveys JetBrains did. For example, on their first graph, “Private members accessible from tests” is right near the middle (and also has the largest number in the “Unwelcome Features” graph) , but is the third highest (of 20) at the Kotlin 1.1 Event. “Collection comprehensions” are also interesting in that they’ re in the middle of both positive surveys, but has the second highest negative rating. Again, “Static members…” are in the middle-ish in both positive graph, but have the third highest negative count.
All these numbers are a little confusing as to what people want overall, so I put together a graph of my own which is a combined number. To combine then, I added up the positive numbers from the two graphs and normalized the numbers to a percent of the highest number, which limits the numbers to a maximum of 100. I did the same kind of normalizing with the negative numbers, except I constrained it to 80. I constrained it to 80 because I felt that, since they won’ t have as well averaged of numbers due to only being in one of the two polls, they shouldn’ t have the same amount of weight as the positive numbers. After putting together my graph, I went back and tried 20 and 100 weights for the negative numbers, and it had very little effect on the overall rankings, so I just kept it at 80. I then subtracted the negative numbers from the positive numbers and added a flat amount to make all the numbers positive (for the graph’s sake) . And here’s the result:
So, just as JetBrains concluded, “Truly immutable data”, “Collection literals”, and “SAM conversions for Kotlin interfaces” are the top three contenders, and with a considerable lead, too. The next three are “Multi-catch”, “Slices for lists and arrays”, and “Inline classes/value classes”, with the amount of support dropping at a fairly quick pace.
Now we’ ll go through each feature proposal and I’ ll give you my thoughts on them.
I feel this is practically a must-have if you don’ t want to have to repeat code in your catch blocks. I’ m slightly concerned this is only in 4th place.
I’ m fairly indifferent on this. On one hand, I think they’ d be useful for DSLs (especially using | as a piping mechanism) , but on the other hand, I think these operators will be abused more than most. I probably don’ t have to worry about it, though, due to its low-lying status on the chart.
Nice to have, but not great. Coming in at #7, it will likely be added someday, but not soon.
Oh, HELL no! If you feel you need this, then you’ re not designing your classes for testability or you’ re testing something that doesn’ t need to be tested. Thank goodness that, despite its popularity in the second survey, it still ends up solidly at the bottom of the chart.
With the Jigsaw module system, this will be much more useful than it would be otherwise, since packages will finally be limited to only what the original authors put in; you can’ t just make a random class and declare it to be in a package of some library. On the other hand, generally you have a certain set of the classes in the package in mind to having access to that variable, function, or class, so you should group them into the same module. But if you want everything to have access without putting it ALL into the same module, package-private would allow you to do that. We should probably have it, just in case. Sadly, this will also add a new keyword to the language.
As much as I like the idea, Kotlin doesn’ t really need them due to their nice functions for creating collections. Plus, I would assume that the literals lock you into a particular implementation. That assumption is apparently wrong, though, because supposedly JetBrains figures that, “Particular types of collections created my be determined by libraries/operator conventions.” Until they show me how that works, I’ m surprisingly against this feature. But it looks like most of you want the literals, so I’ m outvoted.
I love these in Python, but I may surprise you by saying that I’ d rather not have them in Kotlin. First, with Kotlin’s super short lambda syntax sugars, a single filter and/or map is nearly as short as a comprehension. Secondly, filter/map are more flexible, since they can be called directly from the collection or from a Sequence, and there are a TON of other functions like them that a comprehension can’ t use. Lastly, they’ re always confusing to newcomers, which is probably why it’s so low on the list.
I haven’ t needed them much in Python, but they’ re a welcome addition in my book.
I appreciate the effort that JetBrains is giving in order for us to have some semblance of value types, but I think it won’ t be used enough to make it worth it. I could be wrong. Also, they were come up with a syntax that doesn’ t require any new keywords or anything. I’ m not against it, but it’s certainly not a priority to me.
I think we should have this, though I’ m not likely to use it much.
I’ m actually all for both options, which a slight preference for no commas with new lines. Heck, Haskell and Lisps don’ t really use commas at all, and they’ re fine. I feel like the trailing commas option would have done better if it were separate from the other, but I really like both options. Too bad no one else seems to.
I could go either way, and apparently, so can the rest of you.
Type aliases largely take care of this problem, but they don’ t solve all of it. The ability to have multiple non-abstract methods comes in handy, too. Now you won’ t need to use extension methods to add functionality to functions.
What I’ m most interested in with these is whether they can compile micro-optimizations into the code. For example, a @Pure function could somehow be flagged for JVM caching or something. I’ m pretty sure that’s not the case and won’ t ever be, but that would be cool. But, even just using them for static analysis, these could be useful; they’ re not a game-changer, but they are useful. Being in the middle of the list, though, they’ re not likely to happen for a while.
Yes, please! You want to swap variables? Just write “ (a, b) = b to a”. This comes in handy more than you would think, but sadly, most voters didn’ t agree.
Here’s a nice optimization that apparently most people don’ t care about.
