Damian Wieczorek

Personally I would love to see `intentFor` combining both ideas from `startActivity` and `bundleOf`, like [Anko has](https://github.com/Kotlin/anko/blob/93fd14ea606f861082b364df43c76221b135552f/anko/library/static/commons/src/Intents.kt#L63-L64): ```Kotlin inline fun Context.intentFor(vararg params: Pair): Intent { return Intent(context, T::class.java).apply { putExtras(bundleOf(*params))...

> Except even Roman says that was a mistake and it only exists today for backwards compatibility. Do you have a reference for this, by chance? 👀

Have a look at [the existing ideas for `dataarg`](https://youtrack.jetbrains.com/issue/KT-15471) -- it is another approach with similar goals.

How would this be represented in Java? This might also be a good opportunity to bring up built-in type literals for the rest of the language, to replace the java-style...

Another use case is using `SceneView` for non-AR purposes - when using `SceneView`, it should be possible to disable the IBL completely.

How does this relate to #1? Should expression bodies be permitted for long function signatures?

I don't think that `and` is a good candidate. Infix functions should only be used when the operator(s) don't have any implied associativity which could cause confusion when chained together....

Under what circumstances should the functions be in the companion object vs standalone? e.g. the stdlib uses `listOf(...)` rather than `List.of(...)`

> Functions should only be made inline when they use inline-only features like inlined lambda parameters or reified types. I'd make a single exception for extensions meant to implement an...

Also, factory functions using reified types only to access a `Class` should be as short as possible (ideally even a single expression). The bulk of the work that doesn't _need_...