Not really a formal proposal or anything, but I fe...

# language-proposals

[mbstavola]

Not really a formal proposal or anything, but I feel like it'd be really powerful if we could have something like Rust's move semantics-- change the scope in which a reference is valid. I think it could be useful for APIs that consume values, preventing people from reusing stuff after it's passed in.

[Ruckus]

That works really well in Rust where ownership and thread safety are part of the type system, but that isn't true in Kotlin, so I think trying to enforce it would be not only annoying but potentially impossible. (How would you defend against reflection access? How would Java interop work?)

[Ruckus]

But I'm no expert in the matter

[cbruegg]

I wouldn't like to see a halfhearted implementation of Rust's borrow checker in Kotlin, since I guess it would be easy to shoot yourself in the foot with that.

[kevinmost]

@Ruckus

How would you defend against reflection access?

To be fair, val doesn't mean anything either if you use reflection, but we still think it's a good language feature

How would Java interop work?

There's no real way for it to. We do have a few features like reified that don't work in Java though

[Ruckus]

Fair points on both, but reified and coroutines are things you have to explicitly use. What you're talking about is either something that would be implicit on every assign, making all java interop go out the window, or have some sort of new assignment operator that invalidates the object (though since the new operator would be optional, it would be useless).

[mbstavola]

Sorry if I wasn't clear @Ruckus, but I didn't picture bringing the entire borrowing system into Kotlin (though with Kotlin native on the horizon maybe that's not a bad idea).

I was specifically talking about the concept of move, and I think that's totally fine to have as an opt-in keyword or operator. It explicitly gives you knowledge at compile time that a reference is no longer valid after the move, I don't see how that's really useless.

[Ruckus]

And I don't see how it's useful if you have to opt-in. Chances are, we're just envisioning very different use cases. I'm not trying to shut the idea down, just give my input as far as I understand things.

[kevinmost]

you would mark your function as moving the parameter that's being passed to it, and then callers wouldn't be able to use it beyond that point.

Imagine if Closeable.use { ... } could declare that it "consumed" the Closeable (by moving it into its scope). You would have some safety that after closing a resource, you can't reuse it.

Or an Iterable's forEach function could consume it, for example, and you wouldn't try to reuse it

[ilya.gorbunov]

Or an Iterable's forEach function could consume it

There's nothing wrong with iterating an iterable second time. Did you mean an Iterator?

[kevinmost]

Yes, my mistake @ilya.gorbunov

[mbstavola]

Yes, thank you @kevinmost . I wasn't properly explaining myself.

[groostav]

There's nothing wrong with iterating an iterable second time

unfortunately this depends on the source doesnt it?

a sequence that was created off an iterator instance would not be iterable multiple times. the java 8 streams API has a similar characteristic. If we had semantics like these it might be nice to differentiate on types that do support them and types that dont support them.

But I also feel like its worth mentioning that with the propagation of functional programming, we've also been propagating immutable types. Doesn't judicious use of immutable types solve this problem?

[ilya.gorbunov]

@groostav I was talking specifically about Iterable, and not Sequence.

[kevinmost]

interior mutability (again, like Rust, haha) would certainly help out here. 🙂