what are you including them for?

in general if you’re including something it’s preferrable to relocate it to some unique package to avoid this exact issue

I'm using it so that other tools can use the annotations to do analysis.

(E.g. Kotlin can figure out return types are not nullable)

if only Kotlin's runtime took this advice https://kotlinlang.slack.com/archives/general/p1472064891004026

or declared them as a normal dependency

small question: any suggestions on a fancy way to refactor this?

assert(currentRowName!!.equals("weight", ignoreCase = true)
    || currentRowName!!.equals("weights", ignoreCase = true))

avoiding regexes is always preferable

assert(arrayOf(“weight”, “weights”).contains(currentRowName.toLowerCase()))

perhaps. Not sure that it’s better with only two strings though.

could use

in

in that case

assert(currentRowName!!.toLowerCase() in arrayOf("weight", "weights"))

alternatively

lower-casing the value and then skipping

yeah

exactly

I was looking for a sneaky way to get

ignoreCase = true

into the equals operation

when i can just lower-case the source text

is it a redeemable bug that

synchronized

is decompiling with empty

{}

block?

kotlin
    fun next(): Int {
        synchronized(lock) {
            return nextId++
        }
    }

decompiled java
   public final int next() {
      Object var1 = this.lock;
      synchronized(var1){}

      int var4;
      try {
         int var2 = this.nextId++;
         var4 = var2;
      } finally {
         ;
      }

      return var4;
   }

@User uploaded a file: the bytecode looks ok

what's the reason we don't have type inference for constructor args with default values? i can have a field

var x = 0

but in a constructor i need to write

var x: Int = 0

not about Kotlin, but reasons might be the same https://blogs.msdn.microsoft.com/ericlippert/2009/01/26/why-no-var-on-fields/

Wow, had no idea it was technically difficult

Just thought it was a choice thing

well, kotlin already supports type inference on properties and functions

so this can't be the reason

i also think that's something different then the c# issue

since constructors are just like any function this is about function signatures

there use to be a rule that any part of a public API must have a type declared

so that it does not change when you change your default value

this was lifted for public properties later when public became the default visibility

it would be convenient to have this. for expression body methods i also don't have to specify the return type explicitly