Thought it would be a good addition. May be!!

@sree973 https://kotlinlang.slack.com/archives/C0B9K7EP2/p1508774988000003

@alex.krupa Awesomeeeze

object : TypeToken<ApiResponse<<String>>() {}

- How about to extend typealias to expressions?

exp Foo<Gen1, ... GenX> = object : TypeToken<ApiResponse<<Gen1>>() {}
Foo<String,Float....>

exp Foo(param1,... paramX) = fun param1 (param2 : String) ....
Foo(a,b)
fun a(b)

Smth like c++ define

looks like you can do it with

inline fun <reified T> typeToken<T>() = object: TypeToken<T>()

no

@mikehearn describes in his (fantastic) presentation how much pain companion objects cause when creating idiomatic Java API. Main points: - functions and properties require a ton of

@JvmStatic

and

@JvmField

- references to companion objects pollute Java API and IDE code completion I propose reinterpreting currently useless

private companion object {...}

in a way that from Kotlin the companion object cannot be used and companion members can only be called on the class itself, and from Java all companion members are static methods and fields. An example:

class A {
    private companion object {
        val bar = 239
        fun foo() = "hello"
    }
}

, Kotlin:

A.foo()  // ok
A.bar    // ok
A.Companion.foo()  // Error
A.Companion.bar     // Error

, Java:

A.foo();  // ok
A.bar;    // ok
A.Companion // Error

What do you think? Has it been discussed before ?

it's be backwards incompatible, i guess?

Why should we write Java code what aware of Kotlin specifics? Leave Java for legacy code.

Because we might want to have libraries written in Kotlin that also work nicely for Java user, or we might want new Kotlin code to still be usable from legacy Java?

Scope: Like in C# ex:

void myMethod()
{
	{
		// i do something
	}

	{
		// i do another thing
	}
}

@sksk just prefix your scopes with

run

Oh good idea

Here's a made up example to illustrate how this could work: For a Java interface like:

public interface SamJava {
    void many(@NonNull String a,
              @NonNull AccidentalSamInterface b,
              @NonNull AccidentalSamInterface c,
              @NonNull AccidentalSamInterface d,
              @NonNull SamInterface e);

    interface SamInterface {
        void doSomething();
    }

    interface AccidentalSamInterface {
        String getSomeString();
    }
}

In Kotlin we can call it like this:

fun testSam(test: SamJava, x: AccidentalSamInterface) {
    test.many("", x, x, x, SamInterface {  })
}

The variant with all lambdas doesn't make much sense here, we could use

{x.someString}

for middle parameters, but that would generate intermediate objects for no reason.

So, my idea is that Kotlin could generate the third variant for us, equivalent to an extension function:

fun SamJava.many(
        a: String,
        b: AccidentalSamInterface,
        c: AccidentalSamInterface,
        d: AccidentalSamInterface,
        e: () -> Unit
) {
    many(a, b, c, d, SamInterface(e))
}

Then, we could call:

fun testSam(test: SamJava, x: AccidentalSamInterface) {
    test.many("", x, x, x) { }
}

This would find use with every Java API like the

LiveData<T>.observe(LifecycleOwner owner, Observer<T> observer)

that has a SAM type as the last argument that is intended to be passed as a lambda, but has other SAM typed parameters that are not intended to be passed as lambdas.

@Zac Sweers posted very good (subjective of course) abstract guide on keeping discussions productive that seems to be applicable to KEEP project https://gist.github.com/hzsweers/a2bb381aa184b353a383107c1739c964 Maybe we should add these rules ^ to KEEP's readme? ie PR about Type Classes seems to be suffering from the issues described in the guide. Nothing personal, but i don't really find code examples and discussion to be down-to-earth. In the end it's a compile-time ad hoc polymorphism that has different practical applications, but seems to be described too abstractly.

would be nice if type aliases were synonymous for their actual type everywhere?

typealias WhatUp = Workers.State

data class Workers(val whatItIs: State) {
    sealed class State {
        object Working: State()
        object WastingTime: State()
    }
}

fun askWhatup(group: Workers) {
    when(group.whatItIs) {
        is Workers.State.Working -> println("busy yo.")
        is WhatUp.WastingTime -> println("we good.")
//        error: unresolved reference: WastingTime
//        is WhatUp.WastingTime -> println("we good.")
//                  ^
    }
}

Do you have an example where this is useful ?

Actually, everywhere where you now have to introduce specific sub-type just to achieve the same thing, e.g.:

interface SimpleFoo<T> : Foo<T, Unit, Unit>

Introducing a new type just for this is cumbersome. And inconvenient for the users, because they have to know about this type.

Imagine that Android’s

AsyncTask

could be declared as:

abstract class AsyncTask<Params, Result, Progress = Void>

As a note, you don't need a new type. You can use a typealias and it will get compiled away.

typealias SimpleFoo<T> = Foo<T, Unit, Unit>

is there a reason why overwriting methods cannot have default parameters?

I'm forced to do

fun addConstraint(constraint: TypedConstraint) = addConstraint(constraint, disableCollisionsBetweenLinkedBodies = false)
    override fun addConstraint(constraint: TypedConstraint, disableCollisionsBetweenLinkedBodies: Boolean) {

you should have the default parameter in the base class/interface. if a caller has an instance of the interface, how is he supposed to know about default parameters in the implementation?

I do have it in the base interface

backticks are already used to reference functions/properties that have reserved words/characters in them.

I think that could be something like

str.replace('"'.toString(), '\' + '"')

. Either way, both quotes and backslashes aren't exactly the common scenario since they're reserved for both starting/ending a string, and for escaping characters within a string, so I wouldn't want a language feature designed specifically just to make them easier to look at