https://kotlinlang.org logo
Docs
Join the conversationJoin Slack
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by Linen
language-proposals
  • j

    Johannes Zick

    04/06/2020, 4:30 PM
    Hey there, thanks for having me. I know there is a lot of discussion going on about pattern matching, and I know it's hard to do well and correct. But how about we start with a lightweight version, or really just syntactic sugar for destructuring?
    val o = Option.just(1)
    
    val i: Int = when (o) {
        is Some -> {
            val (value) = o
            value
        }
        else -> 0
    }
    
    val i: Int = when (o) {
        is Some(value) -> value
        else -> 0
    }
    This should be exactly equivalent, it could even result in exactly the same bytecode. It's easy to provide conversions in the IDE, one way or another. And it could give a hint if people really use this or if it's just a reflex to want everything others have (not even sure about myself, if we are being honest here). It could be extended in the future, to also do type checks on destructured values (great for Pair), or other checks. Or not. By tying it to the
    is
    keyword for now, it's still open if this syntax will be extended, or dropped again, or will be replaced by something more powerful with a different keyword.
    d
    r
    +1
    10 replies · 4 participants
  • h

    hnOsmium0x0

    04/21/2020, 9:52 PM
    It would be nice to support both classic Kotlin style lambdas for most regular usages
    function() { args ->
        // Blah
    }
    and (optional) Java style lambdas for currying as presented below
    function(curried -> args -> {
        // Blah
    })
    Because in Kotlin's syntax, curried lambdas are really ugly
    function() { curried ->
        { args ->
            // Blah
        }
    }
    Alternatively I think this is acceptable too, if we don't want to sacrifice too much Kotlin's syntax uniformity
    function() { curried -> args ->
        // Blah
    }
    😕 1
    n
    2 replies · 2 participants
  • l

    LastExceed

    04/28/2020, 11:22 AM
    why do i have to type
    val x = ::main
    instead of just
    val x = main
    to store a function in a variable?
    a
    m
    +1
    10 replies · 4 participants
  • l

    LastExceed

    04/29/2020, 9:31 AM
    would it be possible for the compiler to detect that
    else
    is not needed here? right now i HAVE to put an
    else
    , otherwise it wont compile
    Untitled
    a
    g
    +1
    7 replies · 4 participants
  • l

    LastExceed

    04/29/2020, 4:15 PM
    why am i not allowed to return to an outer function from within an inner function ?
    Untitled
    d
    1 reply · 2 participants
  • l

    LastExceed

    04/30/2020, 12:50 PM
    Untitled.kt
    s
    r
    +2
    11 replies · 5 participants
  • l

    LastExceed

    05/01/2020, 12:35 PM
    x should be smart-cast to Int
    Untitled
    l
    r
    +1
    5 replies · 4 participants
  • d

    Derek Peirce

    05/02/2020, 2:22 AM
    Currently, if one wants to perform a
    filter
    followed by a
    map
    on a list, they have two FP-style options that both have drawbacks:
    items.filter { ... }.map { ... }
    requires two separate loops and creates an intermediate list after the
    filter
    step.
    items.asSequence().filter { ... }.map { ... }
    creates two
    Sequence
    objects and cannot inline its lambdas. Both of these fall well short of the optimal
    mutableListOf<T>().apply { items.forEach { item -> if (...) add(...) } }
    performance-wise, but that code is also not nearly as easy to write, read, or debug. One of the goals of a language should be to minimize scenarios where programmers must choose between the code that is most efficient and the code that looks the best. To that end, I propose that we create an inlinable version of
    Sequence
    , or modify the existing class, which will require the ability to create an inline class that contain multiple properties, including lambdas that can then be inlined. For example:
    inline interface Stream<T> { // inline here means that all implementations must be inline, and it should be possible to determine the implementation of any given Stream at compile-time
        fun forEach(operation: (T) -> Unit)
    }
    
    inline class IterableStream<T>(private val iterable: Iterable<T>): Stream<T> {
        override fun forEach(operation: (T) -> Boolean) {
            iterable.forEach { if (!operation(it)) return }
        }
    
    }
    
    inline class FilteringStream<T>(private val sourceStream: Stream<T>, private inline val predicate: (T) -> Boolean): Stream<T> {
        override fun forEach(operation: (T) -> Boolean) {
            sourceStream.forEach { item: T ->
                if (predicate(item)) {
                    operation(item)
                } else {
                    true
                }
            }
        }
    }
    
    inline class TransformingStream<T, R>(private val sourceStream: Stream<T>, private inline val transformer: (T) -> R): Stream<R> {
        override fun forEach(operation: (R) -> Boolean) {
            sourceStream.forEach { item: T ->
                operation(transformer(item))
            }
        }
    }
    
    inline fun <T> Iterable<T>.asStream() = IterableStream(this)
    inline fun <T> Stream<T>.filter(predicate: (T) -> Boolean) = FilteringStream(this, predicate)
    inline fun <T, R> Stream<T>.map(transformer: (T) -> R) = TransformingStream(this, transformer)
    inline fun <T> Stream<T>.toList() {
        val list = ArrayList<T>()
        forEach { item -> list.add(item) }
    }
    After everything is inlined, it would turn this:
    val processedItemNames = items
            .asStream()
            .filter { it.isProcessed }
            .map { it.name }
            .toList()
    into this:
    val processedItemNames = ArrayList<String>()
    items.forEach { item -> if (item.isProcessed) processedItemNames.add(item.name) }
    This would come with the limitation that you can't pass
    Stream
    as arguments to a function or return them from a function, unless those functions are inlined, but I don't think that would pose much of a limitation on their use in practice. Some operators like
    zip
    on two `Stream`s would also be tricky, though zipping a
    Stream
    with an
    Iterable
    or
    Sequence
    would be very doable. When I brought this up on the discussion board, the primary concern was that it's not enough of a performance issue, so I ran some benchmarks. Not only is the optimal code significantly faster than the other two options, using sequences in my example code was actually significantly slower than using lists! https://discuss.kotlinlang.org/t/sequences-and-inlined-lambdas/17228/11 There's also the issue of lambdas creating more bytecode, especially on Java 7, which is problematic for Android, a large motivation of this proposal is to eliminate that bytecode by making these lambdas able to be inlined.
    d
    6 replies · 2 participants
  • e

    elect

    05/04/2020, 9:04 AM
    _
    for function parameters which are unused in the given
    fun
    (but mandatory to match a specific signature type)
    ➕ 10
    👎🏻 2
    1 reply · 1 participant
  • k

    Kirill Shepelev

    05/04/2020, 7:12 PM
    Hey there. I've idea that can be really useful (definitely on Android). Difficult to explain this, but have a sample:
    interface Animal
    
    class Dog : Animal
    class Cat : Animal
    
    fun randomAnimal(callback: (Animal) -> Unit) {
        callback.invoke(Dog())
    }
    
    fun main() {
        // Directly casting parameter to specific type when
        // declaring lambda parameters
        randomAnimal { animal as Dog -> // pay your attention. Here we cast Animal to Dog
            // Do something with dog...
        }
    
        // Safe cast sample
        randomAnimal { animal as? Dog -> // safe cast Animal to Dog
           animal?.let { 
               // Do something with dog...
           }
        }
    }
    d
    j
    +1
    11 replies · 4 participants
  • m

    Marc Knaup

    05/06/2020, 4:55 AM
    Can we support that? 😄 I’d like to return a lambda from a function which can be immediately invoked just like a trailing lambda. Unfortunately it cannot be invoked unless I assign it to a variable first, or call
    invoke
    or put it into parenthesis. Neither make for a good DSL. At the moment to work around that limitation I always have to add two functions: • one that returns a lambda • one that accepts a trailing lambda for immediate invocation and returns
    Unit
    b
    r
    +1
    10 replies · 4 participants
  • p

    pablisco

    05/07/2020, 3:17 PM
    Is there any way to be able to overload a function with another one that receives a suspended function? Like:
    fun doSomething(() -> Unit)
    and
    fun doSomething(suspend () -> Unit)
    I understand that, at least on JVM implementations, this is not possible since both
    () -> Unit
    and
    suspend () -> Unit
    are the “same” because of type erasure. Both are instances of
    Function0
    However, it could be useful when, as an API provider, we want to provide the same api for both without having to use namespacing (like adding a prefix or a postfix) 🙂 Same goes with non coroutine examples like if we want to have overload of operations with generics. Like
    doSomething(intList: List<Int>)
    and
    doSomething(stringList: List<String>)
    If not currently, is there a plans to add this as a language feature? Maybe with namespacing them at compile time.
    c
    e
    6 replies · 3 participants
  • n

    Nico

    05/08/2020, 12:21 PM
    Hi! I am considering submitting a KEEP for pattern matching. You can read a draft here. I have seen some discussion about it here and have drawn from that to write up the proposal. In particular, the case for it matching stuff inside classes and testing for equality is strong if we would like to avoid nested `if`s and `when`s. It of course helps with readability. It is a tried and tested feature in many languages, and Kotlin seems to want to come close to it through destructuring and smart casting but it's not quite there. I suggest using those existing semantics to make pattern matching intuitive and predictable. I would love to receive some feedback/contributions on the draft, and if there is enough support, to follow through with an actual KEEP submission. Cheers!
    🎉 5
    👏 5
    👀 2
    👍 15
    d
    m
    +1
    100 replies · 4 participants
  • z

    Zac Sweers

    05/13/2020, 7:33 PM
    Has there ever been a discussion about more idiomatic union types in Kotlin? Sealed classes have a lot of limitations compared to conventional counterparts in other languages. I’d love to propose something like this:
    sealed typealias Pet = Dog | Cat | String
    • Keywords already exist. RHS expression syntax would need a little work but it could work • At runtime they’re all just objects getting casted, but there’s plenty of precedent for this (generics) • Self-contained in the alias expression • Doesn’t allow anonymous expressions like typescript or similar languages do, which I think is a net positive • Can be compiler-checked just like sealed classes but without requiring inheritance. Instance check just results in a smart cast like sealed classes or other instance checks do today
    when (somePet) {
      is Dog ->
      is Cat ->
      is String -> 
    }
    💯 9
    👍 17
    r
    s
    +6
    146 replies · 9 participants
  • e

    elect

    05/22/2020, 3:04 PM
    emptyMutableMap()
    ?
    s
    b
    3 replies · 3 participants
  • v

    vngantk

    05/27/2020, 2:05 PM
    This new JVM language Concurnas: https://concurnas.com/index.html seems to have a lot of features that we want to have in Kotlin. Any idea?
    🤘 1
    🚫 2
    l
    c
    +2
    31 replies · 5 participants
  • l

    louiscad

    05/27/2020, 3:47 PM
    (just added the ⚠️ emoji as a prefix to the topic)
    👍🏻 4
    m
    2 replies · 2 participants
  • m

    Marc Knaup

    05/28/2020, 10:07 AM
    I’d love to see reified constructors so that I have all information about generic type parameters. I’d use them to replace problematic Java type token hacks when writing BSON/JSON/GraphQL serializer base classes. And it would even work in multiplatform!
    open class Generic<T: Any> private constructor(
       private val type: KType
    ) {
    
       inline <reified T> constructor():
          this(type = typeOf<T>())
    }
    Does anyone else have good use cases for this?
    👍 2
    s
    d
    +1
    7 replies · 4 participants
  • e

    elect

    05/29/2020, 8:35 AM
    I was looking at the features of concurnas, and one thing I also wished to have in kotlin is to have the possibility on
    Any
    to overwrite a default
    toBoolean()
    . This would by default evaluate
    true
    , for not nullable objects. (https://www.concurnas.com/docs/controlStatements.html#toboolean)
    class MyCounter(var cnt: Int = 0) {
      override toBoolean() = cnt > 0
    }
    var counter: MyCounter? = null
    if(counter) // -> false
    ...
    counter = MyCounter()
    if(counter) -> false
    ..
    counter.cnt++
    if(counter) -> true
    ..
    e
    c
    +1
    16 replies · 4 participants
  • b

    Ben Woodworth

    05/29/2020, 7:44 PM
    Here's something I've been pondering, and I'm curious what thoughts you guys might have. (I'm looking at this from a JVM perspective) What if
    equals()
    ,
    hashCode()
    , and
    toString()
    were removed from the
    Any
    class? (And maybe moved into an interface like
    Data
    , or just left to be added as operator functions) For a majority of the classes I write, these methods aren't implemented, and it would never make sense for them to be used. The default implementation of
    equals()
    only checks for identity, so === should be used instead in all cases, and
    toString()
    returns a practically useless String like
    "MyClass@6ea12c19"
    . I couldn't think of a good reason for them to be included in
    Any
    , and Googling around I couldn't find anything on the thought process behind including them. (I am still curious to know if there was a reason) For interop with the JVM, they could be treated the same as the
    java.lang.Object
    class's
    ::finalize
    ,
    ::clone
    , etc. methods, which weren't carried over to Kotlin's
    Any
    . (but can still be implemented without being marked with
    override
    ) I don't think bytecode compatibility would be a problem, since the methods still exist on the JVM. Existing usages of
    Any.equals(...)
    on classes that don't implement
    equals
    could still compile, but with a warning that
    ===
    should be used. The same for
    Any.toString()
    , with a warning saying that the value might not be useful. For code compatibility of existing usages, extension functions could be added to the standard library, similar to this for `toString()`:
    fun Data?.toString() = this?.toString() ?: "null"
    
    @Deprecated("Does not have a useful String representation")
    fun Any.toString() = (this as java.lang.Object).toString()
    
    @Deprecated("Does not have a useful String representation")
    fun Any?.toString() = this?.toString() ?: "null"
    The only incompatible thing I can think of is the override modifier on these functions in existing classes. Allowing
    override
    on them but giving a warning that it's not needed could suffice.
    i
    l
    +1
    4 replies · 4 participants
  • e

    efemoney

    06/03/2020, 1:17 AM
    I really want to be able to do this in kotlin :(
    val Application.cronUsername by this.environment.config
    this
    will refer to the receiver ie the
    Application
    . Is there any limitation I’m missing why its not possible right now?
    g
    n
    11 replies · 3 participants
  • g

    GarouDan

    06/10/2020, 11:50 PM
    Refactored: Following the suggestion, I’d like to post a use case here. The proposal is to create new operators ourselves, like
    !
    (in the end),
    /.
    ,
    @
    ,
    ->
    and also create lists in this way
    {1, "2", a}
    , instead of
    listOf(1, "2", a)
    . I’d like to mimic as much as possible the Mathematica language in Kotlin. A valid Mathematica code is:
    N[
    	D[
    		Normal[
    			Series[
    				Integrate[
    					Zeta[x],
    					x
                    ],
    				{x, 0, 6}
                ]
            ],
    		{x, 2}
        ] /.x -> 15,
    	10
    ]
    and in Kotlin, I’d like to run something like this:
    val x = "x"
    
    n(
    	d(
    		normal(
    			series(
    				integrate(
    					zeta(x),
    					x
    				),
    				{x, 0, 6}
    			)
    		),
    		{x, 2}
    	) /. x -> 15,
    	10
    )!
    Where the
    n
    ,
    d
    ,
    normal
    , etc., objects have a special
    toString
    method, and
    /.
    binary operator would do something with the previous and next argument and the
    ->
    would be another binary operator. In some way, these binary operators are similar to
    +
    and
    -
    binary operators. At the moment the following works in Kotlin:
    val x = "x"
    
    !n(
    	d(
    		normal(
    			series(
    				integrate(
    					zeta(x),
    					x
    				),
    				listOf(x, 0, 6)
    			)
    		),
    		listOf(x, 2)
    	) + "/. $x -> 15",
    	10
    )
    Also, a lot of different operators would be hopefully needed since it is used in this grammar, like the
    @
    ,
    @@
    , etc. So the proposal is have the possibility to create the
    /.
    ,
    ->
    ,
    @
    ,
    @@
    and other operators (to mimic the grammar) and also create lists in this way
    {1, "2", a}
    , instead of using
    listOf(1, "2", a)
    .
    l
    e
    +1
    32 replies · 4 participants
  • j

    jaqxues

    06/29/2020, 5:03 PM
    Yes this goes a bit into 
    constexpr
    So I want to make my App a bit harder to reverse engineer. There are only a few critical points that are actually important, in this case `String`s. So what I would love to do, just to make it a bit harder (I do know very well that it is still absolutely possible to get the strings), I want to encrypt the `String`s into encrypted `ByteArray`s Kotlin has everything in place to allow for an extremely nice implementation
    val encryptedStringExample by encryptedString { "Some_Secret" }
    The Delegate uses a
    constexpr
    to go from the String to an encrypted ByteArray and stores it as field. Hence the String itself cannot be found in the actual compiled code. The decrypted value is just the getValue operator of the delegate.
    println(encryptedStringExample) // Some_Secret
    However, Kotlin does not yet support
    constexpr
    and the "Some_Secret String would always be found in the (Jvm) Bytecode, even with all fancy inlining etc. So my question / request is, is there any news on this? (https://youtrack.jetbrains.com/issue/KT-14652). Or do you have any other ways to offer to achieve this or something similar? Of course I do understand that the key would have to be final to allow to be used for a constexpr (so it really just is to make it harder to find the string in the first place), but this could be useful for some other use cases too
    g
    4 replies · 2 participants
  • j

    janvladimirmostert

    07/05/2020, 12:45 PM
    Proposal: when a lambda has a return type of
    Any?
    , treat a non-valid expression on its last line as Unit instead of complaining that non-valid-expression is not
    Any?
    See the example below:
    inline fun foo(action: String = "Unknown", f: (bar: String) -> Any?): String {
        f("TESTING")
        return "DONE"
    }
    This currently works
    fun doSomething() {
        var k : Int = 0;
        foo(action = "DoSomething") {
            // Empty lambda's return type seen as Unit
        }
    }
    This too works
    fun doSomething() {
        var k : Int = 0;
        foo(action = "DoSomething") {
            k++ // return type seen as Int
        }
    }
    This doesn't work
    fun doSomething() {
        var k : Int = 0;
        foo(action = "DoSomething") {
            k = k + 1      // <<--- "Expected a value of type Any?"
        }
    }
    Workaround
    fun doSomething() {
        var k : Int = 0;
        foo(action = "DoSomething") {
            k = k + 1
            
            "Garbage value to please compiler" // now it compiles fine, return type seen as String
        }
    }
    Also see the comment on YouTrack
    Concerning Unit, 6.6.3 of spec says -  "...This type may be used as a return type of any function that does not return any meaningful value."  I think lambdas and blocks whose last statement is an assignment qualify as not returning any meaningful value.
    https://youtrack.jetbrains.com/issue/KT-20215
    d
    k
    +1
    17 replies · 4 participants
  • z

    Zac Sweers

    07/19/2020, 6:22 AM
    Not sure if this is the right channel, but has there been any externally-contributed KEEP accepted since the process started?
    🤔 7
    e
    1 reply · 2 participants
  • p

    pablisco

    07/28/2020, 9:57 AM
    Before I open a feature request or make a compiler plugin, I thought I ask... Is there a way to restrict DSL calls? For instance, to allow calling a certain function only once (or X amount) as well as maybe restricting the order they are called...
    p
    d
    +4
    18 replies · 7 participants
  • m

    mandeep

    08/04/2020, 8:25 PM
    Curious to hear everyones thoughts. I wanted to expand on class delegation to also work with a
    List
    of some type. For example:
    interface Base {
        fun print()
    }
    
    class BaseImpl(val x: Int) : Base {
        override fun print() { print(x) }
    }
    
    class Derived(val b: List<Base>) : Base by b
    // or maybe use varargs
    class Derived(vararg val b: Base) : Base by b
    The
    Derived
    class would just iterate over the list and invoke whatever is being overridden. This is really useful in scenarios when you can only register a single instance as a callback to something
    g
    d
    9 replies · 3 participants
  • m

    Marc Knaup

    08/07/2020, 6:57 PM
    Explicit API should also warn about implicit constructors being
    public
    . For example I often use factory methods for classes and sometimes forget to make the constructors of these classes
    internal
    , which is unexpected API surface.
    l
    i
    3 replies · 3 participants
  • r

    Ruckus

    08/08/2020, 9:08 PM
    Proposal: Add ability to add "extensions" to a "type" for a cleaner reified use. For example, it's now possible to define a function like
    inline fun <reified T: Application> launch() = Application.launch(T::class.java)
    which can be used like
    launch<MyApp>()
    . It would be pretty slick if you could instead do something like
    MyApp.lauch()
    that would do the exact same thing. This is a very minor thing with very little benefit over looks, but I figured I'd suggest it. Before any one suggests it, no, companion objects won't solve the problem as this needs to be generic.
    j
    h
    +2
    11 replies · 5 participants
  • m

    Marc Knaup

    08/09/2020, 5:40 PM
    @LowPriorityInOverloadResolution
    should be public. It’s so useful to resolve ambiguities 🙂
    💯 3
    ➕ 8
    i
    2 replies · 2 participants
Powered by Linen
Title
m

Marc Knaup

08/09/2020, 5:40 PM
@LowPriorityInOverloadResolution
should be public. It’s so useful to resolve ambiguities 🙂
💯 3
➕ 8
i

ilya.gorbunov

08/12/2020, 3:39 PM
LowPriorityInOverloadResolution
may look as a last-resort hammer to solve an ambiguity, but it's inherently limited because it only helps if there are no more than two conflicting overloads. It's better to find a way to resolve such conflict by means of existing language features than to manually hack the overload resolution, see for example this situation: https://youtrack.jetbrains.com/issue/KT-16255#focus=Comments-27-1904640.0-0 Please report your cases when you wanted to use this annotation, so we could consider it on case-by-case basis. Meanwhile, we have some plans of making such annotations public, but requiring an explicit opt-in.
m

Marc Knaup

08/12/2020, 4:06 PM
Thank you for the info!
View count: 6