kotlinlang #language-proposals

Docs

Join the conversation Join Slack

Channels

100daysofcode

androidgithubprojects

cincinnati-user-group

competitive-programming

event21-community-content

java-to-kotlin-refactoring

jvm-ir-backend-feedback

kotlin-multiplatform-contest

kotlinultimatechallenge

myndocs-oauth2-server

naming

navigation-architecture-component

practical-functional-programming

proguard

prozis-android-backup

refactoring-to-kotlin

russian-kotlinasfirst

skia-wasm-interop-temp

stayhungrystayfoolish

swagger-gradle-codegen

tricity-kotlin-user-group

Channels

language-proposals

elect

12/15/2017, 2:03 PM

I also find a little bloody

((A) -> B)?

, but the alternatives look worst

➕ 6

jkbbwr

12/15/2017, 3:38 PM

typealias init = (Int) -> Int

fun main(args: Array<String>) {
    val a: init? = null
    
}

👍 4

natpryce

12/15/2017, 3:43 PM

Would it be possible for inline functions like

let

apply

also

, etc. to work with tail recursive functions? For example, I’d have thought the following two functions were the same, but the

foo2

is not tail recursive.

tailrec fun foo1(acc: Int, x: Int?): Int? =
    if (x == null) {
		null
    } else if (x <= 0)  {
        acc
    } else {
        foo1(acc+1, x-1)
    }


tailrec fun foo2(acc: Int, x: Int?): Int? =
    x?.let {
        if (it <= 0)  {
        	acc
    	} else {
        	foo2(acc+1, it-1)
    	}
    }

karelpeeters

12/16/2017, 8:09 PM

You can do something like this already, put an

operator fun invoke

in the companion object.

👍 1

elect

12/17/2017, 6:55 PM

is there already an issue about having a

return

inside a constructor? Because right now I'm forced to use multiple

if-else

with the consequent indentations

benleggiero

12/17/2017, 6:56 PM

I’m not sure

return

makes sense in a `constructor`…

oblakr24

12/19/2017, 8:35 PM

Hi Kotlin team, is there any chance we might get extendable enum classes in Kotlin? Right now the way to do this is to have sealed classes which can extend from other case classes, but this is not optimal since these are not singletons and probably there's performance reasons too (I want to cover hundreds of enumerations). Use case? If I have an enum with 200 members, some should be grouped in a separate subcategory as to no litter other subcategories where others don't make sense.

voddan

12/20/2017, 4:17 PM

Was there an issue to implement loop merging for chains of collection transformations (

map

filter

, etc)? I remember some discussions going, but I can't find the issue.

dsavvinov

12/22/2017, 10:12 PM

I'd like to add, that, still, forced-exhaustive

when

can be quite nice in some use-cases, and we're aware of that. It's just not the first-priority feature currently.

👍 4

Slackbot

01/04/2018, 9:34 AM

This message was deleted.

ianbrandt

01/08/2018, 6:53 AM

Greetings All, Any thoughts on adding support for using the spread operator with `Iterable`'s? It would make it easy to create arrays and collections from them, e.g.:

val bowlingFrames = arrayOf(*1..10)

Also:

val notAnArray = listOf(1, 2, 3)
val list = asList(-1, 0, *notAnArray, 4)

(https://discuss.kotlinlang.org/t/arrays-from-ranges/5216) Update: Looks like I'm late to the party with this one: https://youtrack.jetbrains.com/issue/KT-12663.

➖ 1

➕ 2

dh44t

01/10/2018, 6:19 PM

We'll have good news regarding Arrow soon

poohbar

01/11/2018, 1:54 PM

I am against language support for partials and currying. The code is less readable, there is nothing pragmatic about it and it increases the cognitive load ten-fold. Clojure/Scala have both, why not use it and leave Kotlin be?

niccorder

01/11/2018, 6:53 PM

https://github.com/pocorall/scaloid/blob/master/scaloid-common/src/main/scala/org/scaloid/common/logger.scala is a relatively simple example

raulraja

01/11/2018, 6:57 PM

@orangy it's not really the same because with delegation you have to carry over the params in the declarations of the partially applied function. Not arguing the example above it's worth a lang feature just displaying an example where it's frequently used which is function arguments decomposition.

val getPremiumWithTotal = CreditCard.getPremium(creditCards.length) _ 
fun getPremuimWithTotal(creditCard: CreditCard) = CreditCard.getPremium(creditCards.length, creditCard)

@Ruckus It's an improvement because depends on how they are implemented in the lang the value

creditCards.length

can be memoized vs recomputed.

orangy

01/11/2018, 7:50 PM

Okay, if this, then if we can infer parameter types for lambdas so this works:

val getPremiumWithTotal = { cc -> CreditCard.getPremium(creditCards.size, cc) }

will it be sufficient? Not much more than a single and to my taste confusing

after something that looks like a function call

orangy

01/11/2018, 7:56 PM

I might need to remind, that many functional languages are based on sequential composition (tuples, params, etc), while Kotlin and other OOP-style languages are using nominal composition. It’s confusing to mix the two (and we have reports when people try to do

val (width, height) = point

and such), so if possible, I wouldn’t add more confusion here. E.g. given

fun f(a: String, b: String)

, how do you use PA to bind first or second parameter to some value?

ilya.gorbunov

01/11/2018, 7:57 PM

::f.partial(b = value)

orangy

01/11/2018, 8:09 PM

So, if we step away from functional language for a moment, and say that we are not doing “partial application” (we are always doing complete applications, before we ship to customers!), then we are still talking about “bound function references”, only that we can bind any parameter, not just a receiver. And a syntax is this:

receiver::f(_, _, value, _, complex.expression())

, or with the use of named arguments

receiver::f(paramName = value)

. I don’t see a good syntax for unbound receiver though, because

::f

is already reserved for functions without receivers.

👍 3

cedric

01/11/2018, 11:19 PM

class Student(name: String, age: Int)
fun createYoungStudent(name: String): (String) -> Student = { Student(name, 18) }

dalexander

01/12/2018, 4:20 PM

I’m not sure that there’s a conflict between OOP and PA. As Ilya pointed out earlier, PA can be looked at the general case of bound method references, except parameters as well as the receiver can be bound. Using the imaginary _ syntax to indicate parameters which are left open:

fooObject::fooFunction

is the same as

{ p1, p2, p3 -> fooObject.fooFunction(p1, p2, p3) }

fooObject::fooFunction("value1", "value2", _)

is the same as

{ p3 -> fooObject.fooFunction("value1", "value2", p3) }

If we want a general FooObject::fooFunction with the first two parameters applied but not bound to an object then

FooClass::fooFunction("Hello", "Functional", _)

would be the same as

FooClass.(String) -> Unit = { p3 -> this.fooFunction("Hello", "Functional", p3) }

I haven’t seen this mentioned, but one of the major advantages for having language support for PA would be the preservation of parameter names (and parameters with default values?), which tend to be lost with library-provided PA as far as I’ve seen. I don’t know how frequently I would use this feature in Kotlin, but it seems like it would fit reasonably well with the rest of the language, so I’d like to see examples or edge cases where there would be issues.

👍 3

raulraja

01/12/2018, 7:19 PM

Also

def

for

fun

😉

👍 1

:trollface: 2

raulraja

01/12/2018, 8:44 PM

I think so, since in Java you can't enforce it. To make a java compatible edge it would have to be like:

fun javaApi() = run { effect() }

or something along those lines

orangy

01/12/2018, 8:46 PM

Very general note on language design. Someone from C# design team, don’t remember who exactly told me about a principle I like very much. They start any feature/proposal/idea with the “-200 points”. That means, that unless there are at least 200 points in favor of the feature, they don’t even start designing it. It’s arguable how much each argument/use case/etc adds to the pile, but in general, if you keep in mind that there are no free features (not in terms of JetBrains investment, but in terms of burden added to the language, cost of learning, etc) and that you need to have a very compelling reason to introduce this or that, it makes discussions much more constructive. Just a note.

➕ 13

Ruckus

01/12/2018, 8:55 PM

Fair enough

cedric

01/13/2018, 5:14 AM

To me, the best way to get a language proposal to be looked at is to 1. Show a piece of mediocre code 2. Show how that code gets improved with the proposed feature. Then the next step is to see if there's general agreement about the respective merits of both pieces of code and then to see if the code can be improved without adding a new feature to the language (e.g. library approach). Failing that, the language proposal has a good chance to be seriously looked at.

➕ 10

andyfleming

01/16/2018, 7:56 AM

Has there ever been discussion of inferred implementation of an interface (similar to go interfaces)?

alex.hart

01/16/2018, 2:09 PM

Furthermore on interfaces, has there been discussion around finalization of default implementations?

cedric

01/16/2018, 2:17 PM

How about

myList.last

snrostov

01/25/2018, 9:22 AM

Is there any dicussion about operator functions for getting and setting properties? Example:

class Builder<T> {
    operator fun <V> getProperty(key: KProperty1<T, V>): V
    operator fun <@kotlin.internal.OnlyInputTypes V> setProperty(key: KProperty1<T, V>, value: V)    
}

class MyUser(val name: String, val age: Int)

fun buildUser() {
    val userBuilder = Builder<MyUser>()

    userBuilder.name = "test"
    userBuilder.age = 132    

    // should be compiled to:
    // userBuilder.setProperty(MyUser::name, "test")
    // userBuilder.setProperty(MyUser::age, 132)   

    // @OnlyInputTypes is required to disallow userBuilder.name = 123, since R in KProperty1 is contravariant
}

Another use case is LINQ:

class Expression<T> {
    operator fun <V> getProperty(key: KProperty1<T, V>): Expression<V>
}

fun Expression<T>.equals(other: Expression<T>): Expression<Boolean> = TODO()
fun Expression<T>.greater(other: Expression<T>): Expression<Boolean> = TODO()
fun Expression<Boolean>.and(other: Expression<Boolean>): Expression<Boolean> = TODO()

inline fun <reified T> query(predicateProvider: Expression<T>.() -> Expression<Boolean>) = TODO()

fun makeQuery() = query<MyUser> { (name == "test") and (age greater name.size) }

// lambda should be compiled to:
// (getProperty(MyUser::name) == "test") and (getProperty(MyUser::age) greater getProperty(MyUser::age).getProperty(String::size))

Second use case may be also covered by expression trees, but first likely not.

Title

snrostov

01/25/2018, 9:22 AM

Is there any dicussion about operator functions for getting and setting properties? Example:

class Builder<T> {
    operator fun <V> getProperty(key: KProperty1<T, V>): V
    operator fun <@kotlin.internal.OnlyInputTypes V> setProperty(key: KProperty1<T, V>, value: V)    
}

class MyUser(val name: String, val age: Int)

fun buildUser() {
    val userBuilder = Builder<MyUser>()

    userBuilder.name = "test"
    userBuilder.age = 132    

    // should be compiled to:
    // userBuilder.setProperty(MyUser::name, "test")
    // userBuilder.setProperty(MyUser::age, 132)   

    // @OnlyInputTypes is required to disallow userBuilder.name = 123, since R in KProperty1 is contravariant
}

Another use case is LINQ:

class Expression<T> {
    operator fun <V> getProperty(key: KProperty1<T, V>): Expression<V>
}

fun Expression<T>.equals(other: Expression<T>): Expression<Boolean> = TODO()
fun Expression<T>.greater(other: Expression<T>): Expression<Boolean> = TODO()
fun Expression<Boolean>.and(other: Expression<Boolean>): Expression<Boolean> = TODO()

inline fun <reified T> query(predicateProvider: Expression<T>.() -> Expression<Boolean>) = TODO()

fun makeQuery() = query<MyUser> { (name == "test") and (age greater name.size) }

// lambda should be compiled to:
// (getProperty(MyUser::name) == "test") and (getProperty(MyUser::age) greater getProperty(MyUser::age).getProperty(String::size))

Second use case may be also covered by expression trees, but first likely not.

Ruckus

01/25/2018, 4:23 PM

Personally, I don't see how that's much better than using the

get

and

set

operators, in which case it would just be:

userBuilder["name"] = "test"
userBuilder["age"] = 132

snrostov

01/25/2018, 4:25 PM

in your example it is not that type safe. in the provided example you can set only properties of

MyUser

also ide completion will not work

Ruckus

01/25/2018, 4:26 PM

I don't see how your proposal is any different, so I must be missing something.

Ah, wait, I misread. I see the difference.

snrostov

01/25/2018, 4:27 PM

you cannot call

Builder<MyUser>().setProperty(AnotherObj::anotherProp)

, only

MyUser

properties will be accepted

Ruckus

01/25/2018, 4:29 PM

I see that now. I can't say I'm a fan of the idea, but I'm sure there are many that are (I've never particularly liked LINQ)

View count: 6