Some proposal for detail design

1

Kotlin need a colon support in Map like

mapOf("1" : "2", "2" : "3")

semicolon is better than the keyword “to”, “to” is nothing but a misleading (may seem to have some kind of conversion relationship like lamda).

While arrow support for return type is better than colon.

fun test() -> Int {}

because the total function should match a lamdba type. Arrow is more intuitive and match the idea of lambda.

Kotlin is an excellent language , but some detail design is disappointing.

2

“to” is not a keyword, it’s just an infix function.
Kotlin tries to keep a number of keywords to a minimum.

3

I’d recommend giving it time. If the complaint was for collection literals, it might be different. But pure syntax falls into a preference thing. As MikibeMiki points out, to is a nice example of infix functions (arguable more readable in some cases). The colon for function return type matches nicely with how colon is used throughout Kotlin with typing (interface/class implementation, variable type).

Just like how one can learn to switch their preference from next-line braces to same-line braces and back depending on the language and standards, it requires time experiencing the tool in its native environment.
Or like how it could feel absolutely, horribly, utterly wrong to put the type after the name of a variable, you’ll get used to it. You may even prefer it.
Or maybe even the use of fun for function–another thing that occasionally prompts a similar reaction from those new to that form.

Small specific preferences (especially syntax) have a way of shrinking in importance as you get experience with alternative options.

1 Like
4

I would agree that to is not an intuitive name for a functions that creates a Pair but in the case of mapOf I think it is quite natural. You map a key to a value.

And also : = colon, ; = semicolon

5

The colon for function return type matches nicely with how colon is used throughout Kotlin with typing (interface/class implementation, variable type).

Thank you for your reply.
In my understanding , colon means “belong to” or “a kind/instance of ” like interface/class implementation, variable type you mentioned.
But the in the function case, it is totally different, kotlin takes a function(even though a anonymous one) as a lambda object that can be assigned to a variable. Please look at the following code

fun makeIncrementer(): (Int) -> Int {     
    val addOne = fun(number: Int): Int {         
        return 1 + number     
    }     
    return addOne 
} 
val increment = makeIncrementer() 
increment(7)

 // or the following style
fun makeIncrementer2() = fun(number: Int) = 1 + number

What I want to say is that the relationship between function and lambda is very close and unique which can not be cut off or separated easily, so we should try best to ensure their consistency in many aspects as possible as we can to emphasize this functional programmng idea.

Inferred from other use case of colon in Kotlin, a return type after a colon looks like a type of the whole function, however it is not . To emphasize it is just a type of the output but not the function itself, I think an arrow symbol is more intuitive .

And as I mentioned in other reply, infix to may not be a problem , but use to to make a Pair is less intuitive than a and, and use Pair to form a Map is less literally intuitive than Map.Entry in java. Pair can not express a meaning of K-V mapping. For non-native English speakers like me, I think it’s important to accurately express the meaning literally.
This is my opinion, I hope you can get it. Sorry for my bad english.

6

I would agree that to is not an intuitive name for a functions that creates a Pair But in the case of a mapOf I think it is quite natural. You map a key to a value.

I totally agree with you , use to to express map a key to a value is acceptable to me now.
As you say, my be the wired place is it uses Pair to form Map. In this case, Map.Entry in java is more intuitive.
And sorry for my bad English.

7

You make good points. I disagree with some aspects and partially agree with others. Still, it can’t be changed now.

I recommend giving it time and reevaluating after you’ve been using Kotlin for awhile because: these changes can’t be made. Kotlin is past 1.0 and such a breaking changes are not possible. Regardless of the reasons, we have what we have.