We are going to start from array literals in annotations in 1.2, and build full design on top of that.

Are there any plans to support trailing commas?

@adeln if you're willing to trade elegance for performance, you could do

var beforeFrame: View? = null
  var beforeImg: ImageView? = null

  var afterFrame: View? = null
  var afterImg: ImageView? = null

  val v = linearLayout {

    layoutParams = ViewGroup.LayoutParams(wrapContent, matchParent)

    beforeFrame =
        frameLayout {

          beforeImg =
              imageView {

              }
        }.lparams()

    afterFrame =
        frameLayout {

          afterImg =
              imageView {

              }
        }.lparams()
  }

  return PairedPhotoPreviewHolder(v, beforeFrame!!, beforeImg!!, afterFrame!!, afterImg!!)

is there any reason Kotlin doesn’t allow a body inside an annotation class?

Seems impossible on the JVM

Is it possible to simplify delegated properties mechanics to not use

KProperty

, but just

String

for property name?

This channel is for certain proposals, not discussion. If you want just to add some names to properties, you can create annotations that will hold them.

Proposal: Make

-

a part of number literals, so that calls like

-1L.dec()

are the same as

(-1L).dec()

instead of

-(1L.dec())

Yeah... 1 point to Swift I suppose.

a proposal for collection literal val array: Array<Long> = [1, 2, 3] val list: List<Long> = [1, 2, 3] val map: Map<String, Long> = ["a" -> 1, "b" -> 2] so, if type is specified we can use [ ... ] literal

I'd like type aliases to be strongly typed, so you cannot pass differently typed value of the same type.

Please intialize all optionals to null

it'd nice to have

forEachIndexed

offering immediately

i, it

The main question about "strongly typed type aliases", aka "newtype in Kotlin": how would you actually use it, and when you figure out how, how is that different from value types 🙂 ?

We could create some special abstract method for that constructor, and implement it in subclasses for each overridden constructor, but how's that different from an abstract factory method mentioned above?

Hi, I discovered while IntelliJ is fine with nested objects (

object

declared in an

object

) extending an

inner class

of a superclass of the enclosing object, the compiler fails when you do this. I had to replace my

inner class

with a constructor property instead, while the extended inner class would have made it implicit, allowing me to strip the extra val constructor parameter

@benleggiero My immediate reaction was similar to @dmitry.petrov: it’s going to be hard to make a case for this that is not adequately captured by abstract factories. C# offers this concept, so that you can call

new

on a type parameter, but I’ve always found it unnecessary since you can just as well pass a lambda factory method.

data class ApiBuyer ( var id: Int? = null, var customerId: String? = null, var firstName: String? = null, var lastName: String? = null, var addressLine1: String? = null, var addressLine2: String? = null, var city: String? = null, var state: String? = null, var postalCode: String? = null, var country: String? = null, var email: String? = null, var phone: String? = null, var password: String? = null, var status: String? = null, var tripIdPendingRating: Int? = null, var profileImageUrl: String? = null, var pushToken: String? = null, var rating: String? = null, var ratings: Int? = null, var isAdult: Boolean? = null, var defaultToApplePay: Boolean? = null, var applePayCardId: Boolean? = null, var defaultTipPercent: Int? = null, var promoCode: String? = null, var tosAcceptedVersion: String? = null, var createdAt: Date? = null, var updatedAt: Date? = null, var version: Int? = null ) { override fun equals(other: Any?): Boolean { return super.equals(other) } override fun hashCode(): Int { return super.hashCode() } }

Hi, My use case is quite complex (a RecyclerView.Adapter for an Android app), but basically, I'd like smart casts to apply to

check(…)

and

require(…)

stdlib methods. What do you think?

To me, all the value of a data class comes from its destructability

Also

!in

->

is not in

.

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.

A Multi-dimensional array implementation would be cool, similar to the one in C#, rather than using Java's jagged arrays. So you could make a 2x4 array

arr

, and because we know the width and height are fixed to 2 and 4, we can make it a 1D array of length 8.

Interesting workaround..

Sounds like #stdlib

Ok i’ve created one. https://github.com/Kotlin/KEEP/issues/69