4 ms·

Optionally ignoring thread safety seems indefensible -- until you can go full COM and declare your package apartment-threaded, working in a mutable language wit

Optionally ignoring thread safety seems indefensible -- until you can go full COM and declare your package apartment-threaded, working in a mutable language with uncontrolled multi-threading is the deal with the devil you've made and code that doesn't embrace that reality is just broken. Agree about the shadowing. var x_2 = f(x_1) // never use x_1 again for anything deserves its own syntax and compiler checks

kllrnohj 8y ago
> Optionally ignoring thread safety seems indefensible Nobody forces everything to be thread safe. That would either be suicidally complex or suicidally slow. The problem isn't so much "ignoring thread safety", it's that this: class Foo(var thing: Int?) { fun doSomething() { if (thing != null) { thing++ } } } doesn't compile and it should. It fails to compile claiming that 'thing' could have changed in the meantime, so it can't safely assume non-null. However, that can only happen if Foo is accessed from multiple threads, but this isn't thread safe nor pretending to be in the first place. You can make the compiler happy by doing this: class Foo(var thing: Int?) { fun doSomething() { val t = thing if (t != null) { thing = t + 1 } } } But of course that's not remotely thread safe, either. It wasn't thread safe to begin with, and it's still not thread safe now. But this will of course compile just fine. You're forced to jump through hoops to workaround compiler "bugs" To be fair here the warning isn't actually about thread safety at all, it's to guard against something like this: class Foo(var thing: Int?) { fun otherThing() { thing = null } fun doSomething() { if (thing != null) { otherThing() thing++ } } } Kotlin has so far just been unwilling to allow the compiler to handle the cases where it could prove that the variable hasn't been modified in the meantime because they can't always prove it.
- bcoates 8y ago
  They can't ever prove it; even just class Foo(var thing: Int?) { fun doSomething() { if (thing != null) { thing++ } } } is unsafe as any class user could cons up a Foo t, and call t.doSomething() while racing a modification to t.thing in another thread. There either needs to be a language feature for Foo to live in a restricted threading context or the whole construct is irreparably thread-unsafe. The error is valid because it rejects always-incorrect code.
  - kllrnohj 8y ago
    You're again asserting thread unsafe mutations as a reason. It is not. Or if it is Kotlin is just wrong. Guarding against null in an unsafe thread race is pointless to the extreme. That didn't fix anything. It's pointless to complain about it ever. It's a wrong error in that fixing the error doesn't fix the bug in the code. There is no possibility of any kind that my snippet is null-unsafe exclusively. My code is null-safe in all situations where the resulting behavior is also correct. And the compiler could trivially prove that. If they wanted to actually take a stab at compiler-audited thread safety they should add some annotations or such to mark what is guarded by what. Otherwise the only reasonable assumption is to assume thread-compatible. Which my code also runs correctly in.

kllrnohj 8y ago

> Optionally ignoring thread safety seems indefensible Nobody forces everything to be thread safe. That would either be suicidally complex or suicidally slow. The problem isn't so much "ignoring thread safety", it's that this: class Foo(var thing: Int?) { fun doSomething() { if (thing != null) { thing++ } } } doesn't compile and it should. It fails to compile claiming that 'thing' could have changed in the meantime, so it can't safely assume non-null. However, that can only happen if Foo is accessed from multiple threads, but this isn't thread safe nor pretending to be in the first place. You can make the compiler happy by doing this: class Foo(var thing: Int?) { fun doSomething() { val t = thing if (t != null) { thing = t + 1 } } } But of course that's not remotely thread safe, either. It wasn't thread safe to begin with, and it's still not thread safe now. But this will of course compile just fine. You're forced to jump through hoops to workaround compiler "bugs" To be fair here the warning isn't actually about thread safety at all, it's to guard against something like this: class Foo(var thing: Int?) { fun otherThing() { thing = null } fun doSomething() { if (thing != null) { otherThing() thing++ } } } Kotlin has so far just been unwilling to allow the compiler to handle the cases where it could prove that the variable hasn't been modified in the meantime because they can't always prove it.

bcoates 8y ago
They can't ever prove it; even just class Foo(var thing: Int?) { fun doSomething() { if (thing != null) { thing++ } } } is unsafe as any class user could cons up a Foo t, and call t.doSomething() while racing a modification to t.thing in another thread. There either needs to be a language feature for Foo to live in a restricted threading context or the whole construct is irreparably thread-unsafe. The error is valid because it rejects always-incorrect code.
- kllrnohj 8y ago
  You're again asserting thread unsafe mutations as a reason. It is not. Or if it is Kotlin is just wrong. Guarding against null in an unsafe thread race is pointless to the extreme. That didn't fix anything. It's pointless to complain about it ever. It's a wrong error in that fixing the error doesn't fix the bug in the code. There is no possibility of any kind that my snippet is null-unsafe exclusively. My code is null-safe in all situations where the resulting behavior is also correct. And the compiler could trivially prove that. If they wanted to actually take a stab at compiler-audited thread safety they should add some annotations or such to mark what is guarded by what. Otherwise the only reasonable assumption is to assume thread-compatible. Which my code also runs correctly in.