Very simple proposal. Add an extension function to

Double

so you can do this:

0.5.toBigDecimal()

that's not much better than

BigDecimal(0.5)

What was the rationale to not just allow any arbitrary operator? For instance, at work in Swift, I came up with

+?

to append a new element to the end of an array only if that new element is not null.

I don't know if this has been brought up in the whole binary operator discussion, but the current set of binary operators are intentionally defined as experimental infix functions. This is mainly due to the fact that the design could not be finalized yet, as it is interconnected with a whole range of things. See also https://discuss.kotlinlang.org/t/when-does-bit-fiddling-come-to-kotlin/2249 I guess that one of the reasons to go for keywords is partly due to the technical implementation of experimental language symbols. (Maybe JB can confirm/correct?) As far as I understood experimental functions are inlined at call site, leaving no trace of the originally called method, which allows JB to change the language feature without breaking backward compatibility. Regarding the discussion of binary operator symbols vs keywords, I think that readability is the most important factor to tip the decission in favor of keywords to me. The argument that symbols might be compacter and therefore more readable vanishes in the face of the seemingly endles binary expression one liners I came across so far. Generally I liked the point raised before by @jw, that longer keywords encourage splitting the long expressions into several lines or functions and therefore improve readability. In general though we should wait and see what JB will come up during their journey towards propper binary operators/keywords, as it seems like it could be a long one😀

Prefix/postfix functions can get kinda ugly though, pretty sure that's been brought up before

See https://kotlinlang.org/docs/reference/object-declarations.html, notably this paragraph:

Note that anonymous objects can be used as types only in local and private declarations. If you use an anonymous object as a return type of a public function or the type of a public property, the actual type of that function or property will be the declared supertype of the anonymous object, or

Any

if you didn't declare any supertype. Members added in the anonymous object will not be accessible.

I have a proposal: Allow reified exception type parameters in try catch blocks found inside inline functions.

private inline fun <reified E : Exception> throwOrReport(f: () -> Unit) {
    try {
        f()
    } catch (e: E) { //Currently, compiler says: "Reified type is forbidden for catch parameter"
        if (BuildConfig.DEBUG) throw e else <http://Timber.wtf|Timber.wtf>(e)
    }
}

I have a proposal: How about make extension function implement interfaces:

interface SomeInterface {
    fun hi()
}

class SomeClass: SomeInterface {

}

fun SomeClass.hi() {
    print("hi")
}

So, My proposal is that the compiler can infer the interface conformance with the extension function implementation and not show an error in the class declaration. What do you think guys?

There're 2 different things here: 1) Implement an additional interface for an existing class using whatever syntax - not doable in a static language for JVM 2) Allow defining class members outside of the class definition - doable, use cases similar to partial classes in C#, will require more work on the proposal side (starting from extension vs member, probably just use some other syntax) and quite some additional support in tooling, so it needs strong enough motivation.

I was talking about the compiler write the code of this last code to achieve the functionality that I proposed early.

Again, so long as SomeClass and the late-implemented interface are in the same project, I don't see the problem. Just resolve them before they become bytecode

@natpryce I would solve your example by overloading

printStat

to accept

Score

directly. Assuming this did not work for you real use case, what was the problem with it?

iterator()

on buffers and derivates?

CharProgressionIterator

,

IntProgressionIterator

,

LongProgressionIterator

should be serializable. They just have primitives and are good candidates to add the

Serializable

-Interface which will makes ranges serializable

@dmitry.petrov could you possibly give another example?

It seems it could use some cleanup of open issues, some stuff was already implemented and released

Is there any plans about embed objects? At the moment we should write

class Product(val title: String, val description: String)
class Electronics(title: String, description: String, val memory: Long) : Product(title, description)
class Clothing(title: String, description: String, val size: Long) : Product(title, description)

it will more nice to do like

class Clothing(embed product: Product, val size: Long)

and not to duplicate everytime

title: String, description: String

in child constructor

I was thinking about something like this too,

inline

classes. They'd always be compiled down to a parameter list that basically unwraps their values. Might write up a proposal for it when I find some time.

Is there anything you could do with an inline class that you can’t do with an inline func that returns an

object: WhateverInterfaceOrClass()

either way it ends up as a template for the compiler no?

@bamdmux can you show an example?

Hi, I've got a query regarding the new Parcelable implementation in android-extensions which enables you to annotate a model class with @Pacelize. but I'm having issues using it, as my models contains @SerializedName annotation and there are Arraylist properties too. So can anyone help me out?

This message was deleted.

I do not see that message?

Hey, if I wanted to get kotlinx immutable collections into kotlin-stb-lib for forthcoming release, whats the best way for me to participate?

We plan to provide parselling as a serialization backend. So if some data is already serializable, you would not need a wrapper to parcel it.

I don't see how that's any different or better than the parcel adapters that are already in the proposal. In fact, the wrapper allocation makes it seem worse.

Was there no KEEP for the multiplatform changes? If not, where is the discussion taking place for it?

A KEEP for Type Classes as a natural fit of the extension system Kotlin already provides https://github.com/Kotlin/KEEP/pull/87

This message was deleted.