var may be a property in the outer scope, you can create local val with the same name

@mg6maciej Can you check the state of a

lateinit var

?

Toronto hype 😉

This syntax is already in the language if you a willing to prefix your "literal" with a keyword like

arr["a", "b", "c"]

(can be implemented via

get

http://kotlinlang.org/docs/reference/operator-overloading.html#indexed)

...Same goes for maps with an addition of a "pairing keyword"

map {1 + "1"}

(this can be done without generating intermediate objects like pairs)

Also, it’s possible to create a DSL-style map generator, e. g.

map {
    + "k" to "v"
}

Nothing to propose, 🚙 #random

I've got a question concerning inheriting from an abstract class on a data class. Let say we have the following abstract class:

abstract class AbstractExample(
    open val paramOne: Int,
    open val paramTwo: String
)

And, the following implementation of the example abstract class:

data class ExampleImpl(
        override val paramOne: Int,
        override val paramTwo: String,
        val paramThree: Boolean
) : AbstractExample(paramOne, paramTwo)

I have to override

paramOne

and

paramTwo

, because of the following message I get: 'Data class primary constructor must have only property (val / var) parameters' I'd ideally however have an

ExampeImpl

like so:

data class ExampleImpl(
        paramOne: Int,
        paramTwo: String,
        val paramThree: Boolean
) : AbstractExample(paramOne, paramTwo)

Or this at least looks cleaner to me, since this doesn't mean I need to instantiate

paramOne

and

paramTwo

for

ExampleImpl

again and thus use the variables and getter/setter from the

AbstractExample

as I'd prefer to. As far as I know this currently isn't a possibility, hence I dropped in this channel.

so me and a cofounder just spent 10 minutes running down an exception that boils down to a "key not in map exception". One reason is because a junior dev was suppressing the exception, but another reason is because when business rules dictate that a map will contain your key, we simply write

map[key]!!

. I suppose this is our mistake and we should instead write

map[key] ?: keyNotFound(map, key)

but that's clunkey. Could write an extension function but that means we loose the slick square-brackets syntax, and its though to make idioms without them being part of the standard-lib.

It's not for testing, I'm an android developer and it happens fairly often that we have to implement interfaces only to override one method which brings lots of boilerplate code

Hey all. Recently I've created stackoverflow question and then question in kotlin forum about BigDecimal progressions. Here is a link to it: https://discuss.kotlinlang.org/t/kotlin-bigdecimal-progression/3654 In short: kotlin has a progressions. In fact it has Char, Int and Long progressions. One of the sugar things that language supports to them is '..' operations. So you able to write something like (0..10) or (0L..10L) or ('a'..'z'). My question is can it be done for BigDecimals? So I wrote simple implementation of it (based on IntProgression), you can find it in the above link. But main problem is, when you implementing your own progression you not able to write (bigDecimal1..bigDecimal2) since there is no support '..' for BigDecimals. So my question is, can we really implement ranges and progressions for BigDecimals? And if yes, then my proposal is to do it. Thank you. Will appreciate to see feedback.

On the topic of inline functions which return function types: Is it possible/realistic to have an optimization which inlines a return value if it is either: - A: invoked immediately, or - B: passed as an argument to another inline function ... but is not stored in a variable? E.g.

inline val fooFunction: () -> Unit
  get() = { println("hello world") }

fun bar() {
  fooFunction() // immediate invocation results in complete inlining of "println" body
}

I think this is a pretty obscure use case, but could see it being beneficial for something like funKTionale (using partial application, etc)

c# actually has that https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators

Also, in Swift:

var list1 = [1, 2] //mutable
let list2 = [3, 4]  // immutable list

This is the difference between JVM's reference semantic and Swift's struct/class semantics. It is a fundamental difference in the platforms.

If you have a large array named

foo

(let's say it's 1GB) and then you say

var bar = foo

, a "copy" is made, yes. And I'm not 100% sure how, but no delay is incurred. I suspect that you get a new pointer, and any changes you make are reflected as diffs. Also,

let foo = "foo"; let bar = foo

, IIRC, makes

foo

and

bar

point to the same memory, which is safe because neither can be mutated.

There're several possible ways to mitigate this issue, e.g., "this method is available in specializations where type argument

T

is a reference type (or: is a primitive type)".

@benleggiero That would break encapsulation, no?

I was surprised to find Kt does not have null safe index operators arr?[i]. They would be especially useful for traversing nested structures. The closest issue I could find was https://youtrack.jetbrains.com/issue/KT-19168. Its still in the Submitted state. Here's what they look like in C#

I've submitted https://youtrack.jetbrains.com/issue/KT-19444 (Add JVM-specific annotation to permit accidental overrides). What do you guys think about it? I have two concrete issues in my mind this would solve: letting enums implement interfaces and letting properties implement java interfaces with getters

@benleggiero Let's say an object has some hidden state, ie. it doesn't expose a getter and setter for one of its fields. Then I could just come along and write an extention function to read and modify that previously hidden state. See how this doesn't work in practice?

Rather in-depth technical talk about value types in JVM (for those who care): Programming with Minimal Values Maurizio Cimadamore, JVM LS 2017

I looked in the KEEP project and the Kotlin youtrack and didn't see anything about this so I figure I'd propose it here: The current implementation of data classes is really nice, however, creating large data classes can end up creating large constructors. I really like them because they create nicely immutable bundles of data. In java, the builder pattern is usually utilized when constructors start to get large. However, the builder pattern can become quite clunky quickly, even when written by hand in kotlin. A developer could use the google auto-value annotation processor but I don't think this works with data classes. Plus its clunky and you have to deal with IDE configuration. In kotlin named parameters gets around this issue quite nicely because you can selectively specify the fields you want to assign. However, when creating a new instance of a data class in Java you end up with a very large constructor call without any way of knowing what fields you are assigning in the object when looking at the constructor. My proposal is that data classes get expanded to have a static

builder()

method on them that allows data classes created from java to use this builder. Default values that the data classes already have wouldn't be required to be specified in the builder. What are peoples thoughts on this? I'll open an issue in project KEEP if this is worthy of more feedback.

@dmitry.petrov do you know if there are any examples of that out there? I'd love to check it out.

They're discouraged in Golang anyway, I was just trying to think of something new 😅

@dmitry.petrov Do you know if the Kotlin compiler is threadsafe? Meaning, can I invoke it in parallel and let it be safe? Asking because the Scala one for example is not and what I'm doing is evaluating N snippets of code in the fly whose evaluation does not depend on each others results.

i have done this in java with bytebuffers in the past, with limitted success, but a dancing bear isn't amazing because of the skill with which it dances...

We have another solution on the table:

x

in

x as T

should be resolved with an expected type T. So, code like

findViewById(...) as MyView

would work as it did before.

The contract didn't break, that's the point

This message was deleted.