5 ms·

If I'm not mistaken, that's how Swift (which is syntactically most similar to Kotlin as far as I can tell) has it. But "let" is already a thing in Kotlin (a sc

by V-2 4y ago

If I'm not mistaken, that's how Swift (which is syntactically most similar to Kotlin as far as I can tell) has it. But "let" is already a thing in Kotlin (a scope function in the standard library). In my experience, in practice "var" are an order of magnitude more rare than "val", so I'd be perfectly fine with "val" vs. "mutable". I wouldn't mind the verbosity - it would gently discourage the use of mutability, while making it very apparent wherever it's actually involved.

mojuba 4y ago
Yes, it's "let" in Swift and in some (semi)functional programming languages too. > in practice "var" are an order of magnitude more rare than "val" Or rather, it should be that way. Agreed, and I think because the world has been moving more and more towards functional style over the past decades, I'd predict that the next big language that will make it to the mainstream will likely take the approach "immutability by default".
- V-2 4y ago
  On Android - my platform - 99% of var usage is just for the sake of dependency injection, which is an inevitable concession because basic building blocks of an app (like Activities, Fragments) are instantiated by the SDK, not your code, so neither your code nor the libraries it relies on have control over it and thus the DI has to happen "on the fly", by mutating fields as soon as it becomes possible. It leaves a bit of a bad taste still, but it's very much a fixed convention and therefore kind of... compartmentalized, I guess. And harmless, because I don't expect Dagger 2 to suddenly misbehave and forget to set a field.
  - V-2 4y ago
    I mean, in well-architected codebases of course. I've been lucky (or picky) enough to mostly work with such though.
R0b0t1 4y ago
Why not val/mut? Or const/mut, const/var.
- V-2 4y ago
  const is already a keyword - it denotes compile-time constants (basically primitive types). val is constant in runtime, but it can still be computed on the fly; just assigned only once. mut is a nice proposition, I'd certainly consider it if I were to design Kotlin
  - R0b0t1 4y ago
    Interesting. Why not simply overload the meaning of const based on rvalue?
    - mojuba 4y ago
      Like in C++, right? The compiler can decide whether it's a compile-time or run-time constant.
    - V-2 4y ago
      Kotlin's "const" corresponds directly to Java's "const", so my guess is that they don't want to burn bridges with Java where there's no substantial benefit.

by V-2 4y ago

mojuba 4y ago

Yes, it's "let" in Swift and in some (semi)functional programming languages too. > in practice "var" are an order of magnitude more rare than "val" Or rather, it should be that way. Agreed, and I think because the world has been moving more and more towards functional style over the past decades, I'd predict that the next big language that will make it to the mainstream will likely take the approach "immutability by default".

V-2 4y ago
On Android - my platform - 99% of var usage is just for the sake of dependency injection, which is an inevitable concession because basic building blocks of an app (like Activities, Fragments) are instantiated by the SDK, not your code, so neither your code nor the libraries it relies on have control over it and thus the DI has to happen "on the fly", by mutating fields as soon as it becomes possible. It leaves a bit of a bad taste still, but it's very much a fixed convention and therefore kind of... compartmentalized, I guess. And harmless, because I don't expect Dagger 2 to suddenly misbehave and forget to set a field.
- V-2 4y ago
  I mean, in well-architected codebases of course. I've been lucky (or picky) enough to mostly work with such though.

R0b0t1 4y ago

Why not val/mut? Or const/mut, const/var.

V-2 4y ago
const is already a keyword - it denotes compile-time constants (basically primitive types). val is constant in runtime, but it can still be computed on the fly; just assigned only once. mut is a nice proposition, I'd certainly consider it if I were to design Kotlin
- R0b0t1 4y ago
  Interesting. Why not simply overload the meaning of const based on rvalue?
  - mojuba 4y ago
    Like in C++, right? The compiler can decide whether it's a compile-time or run-time constant.
  - V-2 4y ago
    Kotlin's "const" corresponds directly to Java's "const", so my guess is that they don't want to burn bridges with Java where there's no substantial benefit.