Foo := "Hello" // means val foo = "Hello" (Suggestion)

1

I'd like this...

foo := "Hello"

…to mean this:

val foo = "Hello"

This syntax already works well in Go, except that Go uses it to declare variables. I think using it to declare constants would be a better fit for Kotlin though.

2

I don't like this, because it reminds me Pascal language :p But it's only my subjective opinion.

3

What do you mean? Kotlin's CURRENT declaration looks like Pascal:

var kotlinVariable: Any = "Only difference is the semicolon"

var pascalVariable: Any = "This is how it looks in Pascal";

val kotlinConstant: Any = "Bla"

const pascalConstant: Any = "Bla";

I’m suggesting using Go’s syntax, but for values/constants:

kotlinConstant := "Same as Go, except that in Go, this would actually be a variable."

Also, this would fit nicely with Kotlin’s other design decisions like “classes are final by default”; just like you only add the “open” keyword when you actually need it, you would only have to type the verbose “var something =” when you really need a var… in every other case you would just type “something :=”.

4

Honestly, when I discovered Kotlin I really liked to have a syntax like Rust for variable declaration.

val foo = “hello”
var bar = 42

should be

let foo = “hello”
let mut bar = 42

But then I remembered that Scala also imploys these keywords (val and var) for variable declaration. And now I really like this convention. Also it is IMHO a very nice convention to have keywords in front of identifiers like fun, val and var.

5

I disagree, here's why:

Assumptions

  • Immutable is better than mutable
  • Verbosity is bad
  • A programming language should encourage what is considered good

Note that these assumptions are already considered elsewhere in Kotlin, e.g. classes are final by default, if you want to extend something you have to declare it as "open"; there is no corresponding "closed" keyword since "closed" is the implied default.

Java

// Pro: variable declaration is concise:
String someVariable = "initial value";



// Contra: constants are more verbose which encourages use of variables without thinking.

final String someConstant = “More verbose version of variable declaration.”


I tried declaring as many things final as possible once but the code got harder to read because of all that “final” noise everywhere. Nowadays I only add “final” to silence the compiler when I pass something to an anonymous class. Consider this pseudo Java:

mutable String someVariable = "bla";
String someConstant = "immutable";

If it worked like that you'd declare everything as constants and only turn them into variables when you actually need it. So the language would actually encourage the programmer to follow the principle "immutable is better than mutable".

Objective Arguments

  • val and var are hard to tell apart
  • "var" is more verbose than Java
  • it's inconsistent because other Kotlin features only add keywords when deviating from the default choice (there's "open" but not "closed" for classes)
  • "var/val" does not encourage immutable over mutable

Subjective Arguments

  • I used ":=" in Go and it felt right and had no problems. I miss that feature in Kotlin
  • It actually fits Kotlin's syntax rather well. Imagine if you argued for it in two steps:
      1. Make "val" optional, similar to how there is no "mutable" keyword in Java:
        2. someConstant : String = "value"
      2. Simply leave out the type because it can be infered:
        3. someConstant := "value"
    • There are no downsides to using ":=" to declare constants
    6

    So, I have no real background in Go (or Pascal/Delphi). But I occasionaly give small introduction courses to the (very, very elegant) iolanguage, where ":=" has a different meaning (":=" means "create a slot and assign a value to this slot" and "=" means "assign a value to a slot").

    My team and I have a strong background in Java, Groovy (and a bit of Scala), and we see Kotlin as a language with gives us the best of their worlds. This means we are happy, if Kotlin sticks syntactically as close as possible to the aforementioned languages.

    Nevertheless it is interesting to look at the advantages and disadvantages and how it fits best into Kotlin’s design. Here are my subjective counter-points:

    >val and var are hard to tell apart

    Yes, the minimal visual difference could make them harder to tell apart. But the visual difference between “=” and “:=” is smaller. I think the mnemonical meaning is here better than with “:=”. val is for value and var for variable. Even with a mathematical background might “:=” be fine, but “=” has a different meaning in mathematics. Also the IDE helps. It always underlines variables defined by “val”. Also “val” or “var” in front of the identifier gives a nice visual cue with the additional four spaces of indentation. And a keyword in front of the identifier prevents the IDE from suggesting auto-completions, which is good for declarations.

    >“var/val” does not encourage immutable over mutable

    That’s true. But that’s also true with the immutable data structures. The immutable list structure listOf() and the mutable arrayListOf().