So basically if you don't have your own idea for how the language should change, or if your idea is not fully-formed, you can talk about it here without it being considered off-topic andor lost in #general

By the way I start warming up with a question: Any progress in private package or bringing Friend classes to the language? I feel like internal does not fill all my needs.

so yeah, walrus operator?

var next = stack.last
    get() {
        field = stack.pop()
        field
    }

var next = stack.last
    get() = field := stack.pop()

overloadable inverse operator?

val i = 2
-i // -2
~i // 0.5

val M = Matrix.ofRows(vectorOf(4, 7), vectorOf(2, 6))
// [ 4 7
//   2 6 ]
-M
// [ -4 -7
//   -2 -6 ]
~M
// [  0.6 -0.7
//   -0.2  0.4 ]

on that note.. I hope I am not alone, but I would really like a "use wingnut-mode" language extension that puts kotlin into the category of overloading any operator to move kotlin from the "designated symbols" quadrant of https://en.wikipedia.org/wiki/Operator_overloading#Catalog to the top-right flexible quadrant. there are great reasons to protect a certain class of platform majorities from anti-patterns. but when you get into scientific and idiomatic equation solving you really want options to make your compiled context as transparent as possible without additional linker steps to add your ecosystem libraries to your type-safe efficiently compiled source code. I see less of this discussion than i would like to. I work routinely with graph notations and equation solvers, and also I deal with python constantly, and I would be more than happy to have such operators as foo[:] and foo[1:] in my own codex of my own equation solvers, and not have to think about what compiler extension i have to write personally to use these

How about a “generic nullable class”. My idea is that instead of nullable and not null, there is a third option “parameterized null” (

<?>

). Than you could do something like this

data class Test<?>(
    val foo: Foo<?>,   // nullable depending on class parameter
    val bar: Bar,      // never null
    val baz: Baz:?     // allways nullable
)
val test1 = Test<?>(getFooOrNull(), Bar(), null)
val test2 = Test<!>(Foo(), Bar(), null)
test1.foo?.doSomething()
test2.foo.doSomething()

This could be used to easily create Builder classes for data classes with immutable values.

just throwing it out how about list comprehensions in kotlin, i made a gem for Ruby support thinking of a Kotlin library for the same

@iex https://kotlinlang.slack.com/archives/C0B9K7EP2/p1515743921000044

Java allows default values for interface fields, so why does Kotlin not allow it? or at the very least delegation 😦

Came across a situation where it would be handy to create a value type that accepted multiple values. For instance Ncurses has the concept of colour pairs where each pair comprises of a id, background colour, and foreground colour. Currently Kotlin's experimental inline classes only allow a single value which limits where inline classes can be used 🙁. Would be nice to do something like this:

inline class ColourPair(val id, val backgroundColour: Int, val foregroundColour: Int) {
    fun generatePairValue(): Int {
        // ...
    }
}

Is there / could there be any way of enforcing named arguments in Kotlin? E.g. adding an annotation of “@UseNamedArgs” or similar would mean that the compiler would throw an error if that function was being called without using named arguments. Could help with code readability etc.

object: myList :by x or object:FooType by x has been kind of the opposite of improvement over intellij "replace inheritance by delegation". my heart leapt high into the air when i learned of this but came down hard when i read the chosen implmentation.

by

should be considered something like

extremelyvisibleaggregatememberVtable

because you basically can only send a call through a one-way wormhole to the instance named unless you manually (and without intellij's help) "replace delegation by overrides" at the container level. there should be

by

, which does what is documented now, and a v2

by

by some other clever infix name which does delegation through the declarator's vtable of that interface.

I'd love to discuss true pattern-matching in Kotlin again. I know, the current stance of jetbrains is "No, no pattern matching, it's to complicated to implement and to complex syntactically to fit kotlins vision" But i'd still like to discuss it more. Do you think it would help Kotlin to have rust / scala-style pattern-matching and destructuring? if not, why not?

Awhile back I asked why kotlin did not add python-esque indexing of arrays/lists, e.g.

val nums = listOf(1, 2, 3, 4, 5, 6)
val firstThree = nums[..2]
val lastThree = nums[-3..]
val trimEndsByTwo = nums[2..-3]

And the issue that I remember (note: not the only issue, perhaps) is that

indexOf

returns

-1

on an unfound element. so

val elementsToSeven = nums[..indexOf(7)]

would return the entirety of

nums

, an unexpected value C# 8.0 skirts around this issue by using

^

instead of

-

as the end-orientation operator, and throws out of range for negative indices.

val lastThree = nums[^3..]

Would kotlin benefit from the same approach? I believe so. Especially given

^

is not currently used at all

Man, I'd love it if keyboards were equipped with more math symbols. Ceiling and Floor brackets could not only serve as "Round up" and "Round down" the singular element contained respectively, but also return the max and min of multiple elements contained within.

I often use inner classes in the following way (honestly don't know other uses for them):

open class Line(open var from: Point, open var to: Point) {
    val reversed = Reversed
    inner class Reversed : Line(to, from) {
        override var from: Point
            get() = <mailto:this@Line.to|this@Line.to>
            set(v) {
                <mailto:this@Line.to|this@Line.to> = v
            }

        override var to: Point ...
    }
}

Where every instance of Line has its own singular instance of Reversed, which only borrows its state from Line, and is otherwise stateless It is here that the idea of

inner object

comes to mind

interface Line {
    var from: Point
    var to: Point

    inner object Reversed : Line {
        override var from: Point
            get() = <mailto:this@Line.to|this@Line.to>
            set(v) {
                <mailto:this@Line.to|this@Line.to> = v
            }

        override var to: Point ...
    }
}

I'm not sure if this is the best nomenclature for this structure, though. Maybe

satellite

? Could this be considered stateless in the same way that any getters/setters are? And thus usable in interfaces?

Is there any way of making certain classes compile as data classes for some builds and normal classes for other builds? Thinking specifically of tests where you might want to use data-class style equals for assertions, but you dont need it in production

Hello everyone 👋🏽 with my team we were evaluating do some changes and base our error handling in the new Result class. I was taking a look at the fold implementation and I realize that the usual order from other languages and libraries is inverted, instead of left for errors and right for success is the other way. I was wondering and getting curious if this has some specific reason? Thanks in advance

public inline fun <R, T> Result<T>.fold(
    onSuccess: (value: T) -> R,
    onFailure: (exception: Throwable) -> R
): R

I'm currently working with a lot of DSL and thus builder-classes, which currently are relatively cumbersome to implement when you want to otherwise work with immutable data-classes. I was thinking about how one could optimize this... serveral solutions come to mind. there is

autoDSL

, a library based on annotation processing that can automatically generate a dsl-style builder for your classes, which is simmilar to what i want, but is rather inelegant, and a library needing kapt - hurting compile-times What would you think about some kind of language-feature that allows for easier building of immutable (data)-classes, like some kind of

buildable

class modifier? I could imagine it being a way to specify that a data-class has some

buildable

fields, that are, as long as the class has not been built, mutable (and also might include

building

-functions, that are only present whilst the object hasn't been built. the modifier could then introduce a new method

create

which turns the buildable class-instance into the normal, immutable data-class instance that you would then use everywhere. this would, in a way, be a way of combining a builder class together with it's fully built, immutable version. for simple data-container-classes, this could be really practical any thoughts?

The reflection is gone, and the properties are no longer adding performance or bytecode overhead, as they’re eliminated before the Kotlin is even compiled to Java. This would require the compiler to be able to make many more optimizations, but it would allow coders to write reflection-like code without deciding between the performance overhead of reflection or the engineering overhead of annotation processors. It could be used to write a custom

equals

or

hashCode

or

toString

implementation that uses fields based on their annotations or types, and to write easily understood serialization and deserialization formats. Another example. If properties are more aggressively inlined, it would also simplify existing code that uses properties. Consider this use of map delegation:

class MapExample(
       map: Map<String, String>
) {
   val x by map
}

When the

by

is inlined, it becomes (effectively):

val x: String get() = map.getOrImplicitDefault(MapExample::x.name)

The decompiled class contains an entire

KPropertyObject

that is used only for its name. Suppose that this name access were inlined, because the compiler knows that the name of

x

is “x”:

val x: String get() = map.getOrImplicitDefault("x")

Now the overhead of involving properties is entirely eliminated. As I work on mobile code where reductions in bytecode size and execution time are top priorities, I would like to have property-inlining features like these to be able to use reflection-like features without their large overhead (We’ve eliminated many uses of

by

because of the unnecessary

KProperty

fields). Would these be feasible for the language, and how useful would they be to you?

Could anyone talk about the current state of the two "type-class"-like KEEP-proposals? (https://github.com/Kotlin/KEEP/pull/176 and https://github.com/Kotlin/KEEP/pull/87) What is their current status? Is there any indication that one of them will be implemented into the language in the "not-so-distant" future?

where is the documentation to work with dates?

Is it possible to add smart cast for such cases?

data class EmployeeDetailedDTO(val firstName: String)

class EmployeesRepository {

    inline fun <reified T> findPage(isDeleted: Boolean = false): List<T> {
        return when(T::class) {
            EmployeeDetailedDTO::class -> listOf(EmployeeDetailedDTO("John")) as List<T>
            else -> TODO()
        }
    }
}

so, it will not be needed to add

as List<T>

Let’s talk a bit about Kotlin’s collection extension methods versus Java 8’s collection default methods, both designed to solve the issue of wanting to add more behaviors to existing collections, usually those that use lambdas, but in very different ways.

list.forEach { println(it) }

The Kotlin extension methods have an advantage in that, because they’re effectively static methods, they can be inlined, which makes this equivalent to:

for (value in list) { println(value) }

Meanwhile, the Java default methods have an advantage in that because it’s a default method, it can be specialized to the collection. For example, if

list

is an

ArrayList

, here’s how its

forEach

is implemented:

public void forEach(Consumer<? super E> action) {
        Objects.requireNonNull(action);
        final int expectedModCount = modCount;
        @SuppressWarnings("unchecked")
        final E[] elementData = (E[]) this.elementData;
        final int size = this.size;
        for (int i=0; modCount == expectedModCount && i < size; i++) {
            action.accept(elementData[i]);
        }
        if (modCount != expectedModCount) {
            throw new ConcurrentModificationException();
        }
    }

This is significantly more efficient than using its iterator, which requires creation and use of an iterator object as well as more frequent

modCount

checks. The cost is that action is no longer inlined, so a lambda object is created instead (either once or per

forEach

call, depending on what is in its scope), and there’s another level of indirection in executing it. Of course, this doesn’t consider additional performance improvements from JIT optimizations, but I would expect that inlining the lambda is much simpler than inlining the logic of an iterator object, and the resulting code would still be more efficient due to the

modCount

checks. However, we haven’t covered another advantage of specialized methods: they can operate significantly more efficiently on their collections. Take, for example, Kotlin’s

getOrPut

method versus Java 8’s

computeIfAbsent.

They are effectively the same in what they do. However,

getOrPut

requires a

get

call that may be followed by a

put

call. On a

HashMap

, this means hashing the object twice and finding the proper location in the proper hash bucket twice. On a

TreeMap

, this means traversing the tree twice. However, `HashMap`’s

computeIfAbsent

is specialized so that as soon as it’s determined that there’s no prior value at the correct hash bucket, the new value can be put in the correct place immediately, without rehashing or renavigating. (Strangely,

TreeMap

doesn’t have a similar specialized

computeIfAbsent

implementation, and I can’t tell why.) There’s also the issue that extension methods, being implementation-agnostic, can’t guarantee that a

ConcurrentHashMap

is operated on safely, while its specialized

computeIfAbsent

can. So where does that leave Kotlin? Are there plans to ever find some way that a more advanced or JIT compiler can benefit from both inlining and specialization, or are we doomed to create iterators over `ArrayList`s forever?

There is a new KEEP that hopes to bring pattern matching and decomposition inside

when

conditions https://github.com/Kotlin/KEEP/pull/213

I see Explicit API mode (https://github.com/Kotlin/KEEP/blob/master/proposals/explicit-api-mode.md) is included in 1.4-M2 such that

public

visibility modifier is required. So now all declarations will require either

public

modifier or

private/internal

. Is making

internal

visibility default in this mode on the table?

Hello. I have interest in K/N reflection. If I were interested in doing work to add support for it, what would be involved in that? Is it currently blocked by technical limitations, or would this kind of thing be practical?

(Please tell me if this is more suited for #kotlin-native, I'll gladly move it over)

This message was deleted.