Please add a : operator that maps to to, so that e.g. maps can be written as
mapOf(1:a, 2:b, 3:c, 4:d, 5:e, 6:f, 7:g)
instead of
mapOf(1 to a, 2 to b, 3 to c, 4 to d, 5 to e, 6 to f, 7 to g)
2 Likes
This has been suggested in the context of collection literals for maps, but what I’m proposing here is an operator that will be defined on Any to return a Pair.
If collection literals were implemented, it might make more sense for this to be a Pair literal, as it differs to other operators in that it might never make sense to overload.
I like it more if it returns a map.entree as this can be more useful with the forEach with receivers
Collection literals was the most requested feature from the language survey: https://blog.jetbrains.com/kotlin/2017/06/kotlin-future-features-survey-results/
Your example, though, probably won’t cut it as the : symbol represents a type definition. Python parity is not a goal of Kotlin 
1 Like
It could be a collection literal for Pair.
The only way would be embedded in a collection literal. There would be no way to differentiate
someMethodAcceptingPairs(key1: value1, key2: value2)
from Kotlin named parameters:
someMethod(paramName1: value1, paramName2: value2)
I am 99% sure that named parameters in Kotlin use = instead of :
someMethod(paramName = value1, paramName2 = value2)
btw: how do you change the color? 
Doh! Sorry, been doing a lot of Groovy coding in gradle files lately and it uses : for that
Use ```kotlin. It is somewhere in one of markdown standards.
Ok after some experimenting I have it kind of working. Kotlin needs to be spelled with a capital K and there needs to be a space between ` and Kotlin. But even this is not working all the time … Doesn’t really matter. I thought @dalewking made them red intentionally to highlight them.
I just said that it was code and it apparently highlighted them red because they were not valid.
The downside is that it would be preclude a standard ternary operator (unless it only worked within map literals), because a ternary operator would short-circuit, but a Pair constructor would evaluate both arguments.
I had some groovy background when I came to Kotlin and at first, I also wanted : operator for maps, but after some time it seems that it would brake to many things, and collection literals are overrates. But I wanted to point to another possibility. One of the most brilliant things about kotlin is a possibility to declare some behaviors in a specific context. For example to redefine some operators for specific receivers. For example one could make this:
class MapBuilder{
private val map = HashMap<String,Any>()
operator fun String.rem(obj: Any){
map.put(this, obj)
}
}
fun buildMap(action: MapBuilder.()->Unit): Map<String, Any>{
return MapBuilder().apply(action)
}
val myMap = buildMap{
"a" % 22
"b" % "this is a string"
}
I do not say that this particular way is good, but it could be done. The current state is not bad since typing to requires exactly the same number of key presses as typing :.
The only thing I can see to improve the situation is to add some additional operator which is not used by now like ~ or ^, do not implement it by default and reserve it for attribution and DSLs.
It’s not the typing I’m trying to improve, it’s the reading!
I think that reading suffer in this case only because previous experience with Python/Groovy. I do not think that it is the aim of the JetBrains team to simplify migration from python.
There is a workaround to use more concise syntax for json building in kotlin-js. I’ve shown it here, It allows to use = instead of to and avoid quotes, but I do not think it is possible or even favorable for kotlin-jvm.
1 Like
I’ve never programmed in Groovy (except Gradle builds) and only a little Python. My familiarity with : in this context is from standard English more than any particular programming/markup language, although it’s a very common convention there as well.
If you compare classic Gradle scripts to the equivalent in Kotlin script, you can see how the lack of syntax for literal maps can really make things ugly.
: isn’t an issue of one vs. two characters, that would be trivial. It’s really about standard punctuation vs. a word. If you don’t think that’s siginificant, read a telegram with STOPs in place of periods 
I’d like to point out that the original post was about a : operator in general, not only in connection to collection literals.
I personally prefer to to : in that case. That does not mean that I would not welcome any sort of collection literal. I definitely prefer {...} over mapOf(...) but I guess this comes down to personal preferences.
I can’t think of an example where : would be used in English in any comparable way as suggested here. Can you give an example of that?
This year you will have the following teachers:
Mr A: Subject 1
Mrs B: Subject 2
Mr C: Subject 3
Mrs D: Subject 4
That’s a typical use in English, and is conceptually the same as to.
People are way more flexible than compilers when reading something. People can switch contexts with very little effort from one part of a text to another.
You can of course build a compiler that can also switch contexts, but it won’t be able to do it without effort. And this extra effort will result in longer compilation times. So you need to make trade-offs.
If I use a colon for this feature, I won’t be able to use it for another. Which feature is more important, i.e. will make the language more pleasant, easier to parse and compile, etc.?
In this case the Kotlin team chose to use the colon for type specifications. I guess because type specifications occur more frequently in code than map entries.