Kotlin language feature requests

Language Design
1

Hi there,

I have few feature requests on Kotlin laguage, and I wonder what you think?

  1. I think arrayList and hashMap are so frequently used types that they should have literals contructs. It will make program shorter and faster to type. Something like these are pretty easier to read and understand:

``

val list = [1,2,3]

val map = {“name” : “Zemian”, “city” : “Orlando”}

compare to current Kotlin syntax:

``

val list = arrayList(1,2,3)

val map = hashMap(“name” to “Zemian”, “city” to “Orlando”)

  1. I think “to” function to create a tuple (or multiple assignments now) is a clever way to extend the lang with simple user library, but I tend to prefer a built-in construct for such a frequent used item such as map. I prefer just one symbol charactor rather than two chars. It’s easier to read and type. See above.

  2. I think string key hash map is a very frequent used type that it deserves special literal contruct as well. I specially like Groovy’s map that you can use simple words as key without quoting it.

``

val mapOfList = {

  list1 : [1,2,3]

  list2 : [4,5,6]

  list3 : [7,8,9]

}

Compare that to current syntax is much more compact, easier to use, and less typing.

``

val mapOfList = {

  “list1” : arrayList(1,2,3)

  “list2” : arrayList(4,5,6)

  “list3” : arrayList(7,8,9)

}

What’s more important is that this type of String map construct will support DSL programming much more fluently.

  1. I think allowing methods to be invoke without parenthesis can save many keystroke typings and could* make source easier to read. I understand in some cases these are problematic, and may cause ugly parser logic in the compiler, but it would give programmers much more flexibility and benefits that I think it’s worth it. Again this feature will make some part of DSL API design much more fluent as well.

  2. I don’t understand the reason behind not supporting a “Float” literal construct? I think making user to cast like this is ugly in code:

``

val f = 123.99.toFloat()

Not that I use float type often, but since it’s a support type, and it’s the only type that sticks out like this is pretty ugly to me.

Well that’s all I have for now. I think small things likt these would make programmers more happy in general. What do you think?

Zemian

3 Likes
2

THanks for your feedback.

1, 2. Named functions are good enough. No point in growing the language.

  1. We are considering ruby-like symbol syntax

  2. Too many syntactic problems

  3. Float is just a library class, used infrequently. Why grow the language to support it a tiny bit better? BTW, if you need concise floats so much, you can define an extension property and use it like 1.234.f

3

A Ruby-like :symbol syntax could be interesting, though maybe not as useful as in Ruby, where strings are mutable and symbols are not. They are nice for syntax highlighting though, in that they stand out from strings.

Would :symbols be == to strings? Just another syntax for the same thing.

Of note, Rails implements a HashWithIndifferentAccess because data often comes in from the wire with string keys, but code may try to index it with symbols.

Nathan.

4

Hi,

I agree on the arrays. Especially in annotations it is very “unKotlin” like to declare arrays. The whole language reads so nice and terse - but when it comes to arrays it is too verbose. I can imagine that the algorithm to assess what type of array and how to compile is a lot more complicated than a function approach - but still… it does break the mold of Kotlin.

PS: The toFloat does not bother me. I am glad that Kotlin does not support implicits like Scala (which would have solved this problem), and rather went with extensions. In other words - I will live with the toFloat… or .f.

Regards,
Gawie

5

It’s a pretty old topic :slight_smile: We have actually grown warmer to the collection literal syntax, so some future version of Kotlin might have it

6 Likes
6

That would be awesome, especially if it can be done in an extendable way like the C++11 initializer_list.

Maybe have it plug into the existing vararg keyword?

1 Like
7

I would totally agree with this simpler syntax. It would improve readablility

8

On the other hand:

fun <T> a(vararg items: T) = arrayListOf(*items)
fun <K, V> m(vararg items: Pair<K, V>) = hashMapOf(*items)

val list = a(1, 2, 3)
val map  = m("name" to "Zemian", "city" to "Orlando")

Much terser. So it would be nice, but not needed.
As a compiler writer I’d be worried about the parsing interactions with the lambda syntax.

But if the syntax is introducted, it should probably work like the existing overloadable operators, so that e.g. [1, 2, 3] would be translated to makeListOf(1, 2, 3) and you could define or bring the makeListOf function you want in scope.

2 Likes
9

I know this is a prety old post, but as function literals are now as the number 1 features that the community wants to have…

I don’t know if it is a possible or good Idea, but can we use functions for this.

so
[varargs values: S]
will be translated to createList(varargs values: S)
which returns a class implementing List<S>

and

{varargs values: Pair<K, V>}
will be translated to createMap (varargs values: Pair<K, V>)
which returns a class implementing Map<K,V>

In this way, the literals are not bound to the Kotlin-types, while you know that you get a map or list.

10

about “primary constructor”:
We know. Kotlin does not have an extra primary constructor. In other words, it consists of the class and the block called Init. Salop could be said (reminder) init is the primary constructor.
I find it more consistent and readable if the init is omitted and started directly with square brackets.
What do you think? At first, I wanted to suggest just starting directly under the member variables with the pimary constructor (even without square brackets). Would that be possible?