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
  • i

    igor.wojda

    01/25/2018, 1:10 PM
    Hey what do you thing about dropping requirement of explicitly specifying lambda parameters completely is they are not used at all? Now
    var appNotifications by Delegates.observable(listOf<AppNotification>()) {
        _, _, _ -> notifyDataSetChanged()
    }
    After
    var appNotifications by Delegates.observable(listOf<AppNotification>()) {
        notifyDataSetChanged()
    }
    ➕ 1
    v
    • 2
    • 3
  • j

    jkbbwr

    01/28/2018, 2:43 AM
    So I have a usecase for macros in Kotlin. I want to do lots of unsigned type work. I know the JVM doesn't have unsigned types but manually keeping track of the shifting and types might introduce bugs. If I had macros I could generate it at compile time.
    b
    g
    • 3
    • 19
  • b

    benleggiero

    01/28/2018, 2:54 AM
    Proposal: The
    ?.
    operator shouldn’t be required when we’ve already verified that we’re not working with a `null`value. For instance:
    //                                                       v This proposal focuses on this operator
        val isMac1 = System.getProperty("os.name")?.toLowerCase()?.startsWith("mac") ?: false
    
        val osName = System.getProperty("os.name")
        val isMac2 = if (osName != null) {
            osName.toLowerCase().startsWith("mac")
        } else {
            false
        }
        
        val isMac3 = System.getProperty("os.name")?.let { it.toLowerCase().startsWith("mac") } ?: false
    Here, to get the value of
    isMac1
    ,
    System.getProperty("os.name")
    returns a
    String?
    , and we used a
    ?.
    to handle that. After this operation, we call
    .toLowerCase()
    (which returns a
    String
    ). However, to chain another call (in this case,
    startsWith("mac")
    after that, we need to use a
    ?.
    operator. This baffles me, since
    toLowerCase()
    never returns
    null
    , and we can safely assume it was not successfully called on a
    null
    object, why does the language require that I use a
    ?.
    operator? To highlight why this baffles me, I use another value,
    isMac2
    . The steps to create this are, in my head, identical to the previous. I get the system property, then if it’s not
    null
    , I check to see if its lower-case form starts with
    "mac"
    . If the property was
    null
    after all, I use
    false
    . Here,
    toLowerCase()
    did not require a
    ?.
    operator because the compiler inferred that it was unnecessary since we already did a
    null
    check. To make
    isMac1
    , in my head, we’ve done the same thing, so the same inference should be made. Just for completion, I included another way to accomplish this with
    isMac3
    . I get the system property. If it’s not
    null
    , the
    let
    block is entered, and its lower-case form is checked to see if it starts with
    "mac"
    . If that property was
    null
    , then
    false
    is used. Again, no
    ?.
    operator is necessary to use
    toLowerCase()
    , since we already know nothing here is
    null
    so long as the system property isn’t. Summary: If we’re chaining function calls and know for sure that we wouldn’t’ve gotten this far if some
    ?.
    had returned
    null
    , then further uses of
    ?.
    should only be required on functions that return an optional/nullable type.
    👎 2
    👍 1
    e
    • 2
    • 4
  • k

    kevinmost

    01/28/2018, 3:18 AM
    because you can, at some point, chain a function call without the
    ?
    that will be invoked even if the receiver is
    null
    . For example,
    System.getProperty("os.name")?.toLowerCase().isNullOrEmpty()
    , and a distinction must be made if you want that function to execute no matter what, or only when the receiver is non-
    null
    b
    i
    +3
    • 6
    • 49
  • p

    Pavlo Liapota

    01/28/2018, 8:14 PM
    When I came to Kotlin from C# I also had such thoughts and even wrote an article https://tech.io/playgrounds/7995/difference-between-safe-call-in-kotlin-and-c-sharp but now I like Kotlin syntax
    b
    • 2
    • 1
  • k

    kirillrakhman

    01/29/2018, 12:29 PM
    oh boy, here we go https://github.com/JetBrains/kotlin/commits/rr/zarechenskiy2
    👏 3
    😍 5
    🎉 10
    a
    u
    +9
    • 12
    • 45
  • g

    gildor

    01/31/2018, 5:29 PM
    and what is example of context where it would helpful? I mean some code that an be improved using these extensions
    i
    • 2
    • 3
  • k

    kevinmost

    02/01/2018, 1:50 PM
    Yeah, I'm not sure how
    [action] for [variable] in [collection]
    is more readable than
    [collection].map { [variable] -> [action] }
    . The latter reads left to right perfectly. For the former, you need to read the whole thing to get context on any of it. And it requires special syntax
    ➕ 4
    g
    j
    +2
    • 5
    • 6
  • i

    ianbrandt

    02/06/2018, 12:11 AM
    I love the conciseness that stems from Kotlin requiring variables to be initialized when declared. I also enjoy the terseness of type inference. I think the combination could be improved if Kotlin added short and byte literals. I also think double literals would be more concise if 'd/D' was required. I imagine that ship has sailed, but it would be nice if it was at least supported. Then we could enforce its use by convention with linters. (To preempt any counter arguments of, "Why not
    var i = 0i
    for integers then?", I'll quote David Sedaris, and say that hopefully we can all, "...denounce the very idea as grotesque, and unrealistic." 😉)
    var bool = false // Boolean
    var b = 0b // Byte. Does not compile. Has to be "= 0.toByte()", or "var b: Byte = 0".
    var c = 'c' // Char
    var s = 0s // Short.  As with Byte, does not compile.
    var i = 0 // Int
    var l = 0L // Long. Lowercase 'l' not supported.
    var f = 0.0f // Float. 'F' also supported.
    var d = 0.0d // Double. Does not compile, as 'd/D' not supported.
    g
    b
    • 3
    • 13
  • i

    ilya.gorbunov

    02/06/2018, 12:50 AM
    1b
    can be confused with hexadecimal literal
    i
    b
    • 3
    • 6
  • g

    gildor

    02/06/2018, 3:05 AM
    There are other cases, where you must use toByte(): byteArrayOf(0xB0.toByte(), 0x7B.toByte(), 0x00.toByte())
    i
    b
    • 3
    • 6
  • m

    misko

    02/06/2018, 10:20 AM
    Hey guys, is there any reason that inline operator set is not usable without this in lambda with a receiver? Imho, it could add to the DSL capabilities. Here is an example, where I think this might be useful
    class Json {
        val map : HashMap<String, Any> = HashMap()
    }
    inline operator fun <V> Json.set(key: String, value: V) {
        this.map[key] = value as Any // this is not of importance
    }
    
    fun obj(builder: Json.()->Unit): Json {
        val obj = Json()
        builder.invoke(obj)
        return obj
    }
    
    fun main(args: Array<String>) {
        obj {
            set("1", 1)    // this is ok
            this["2"] = 2  // this is ok
            ["3"] = 3      // this is not - Kotlin: Unsupported [Collection literals outside of annotation]
                           //             - Kotlin: Variable expected
        }
    }
    ➖ 3
    v
    b
    • 3
    • 2
  • k

    karelpeeters

    02/06/2018, 11:39 AM
    Where do you draw the line? Should
    - other
    and
    in other
    also work when leaving out
    this
    ?
    m
    • 2
    • 1
  • k

    karelpeeters

    02/06/2018, 5:29 PM
    Why
    y
    for bytes? I skimmed the linked JDK proposal, couldn't really find any justification there either.
    r
    i
    +4
    • 7
    • 17
  • b

    benleggiero

    02/09/2018, 2:56 AM
    Is that a #stdlib proposal since it can be entirely done in annotations?
    o
    r
    • 3
    • 2
  • i

    igor.wojda

    02/16/2018, 4:19 PM
    We have
    emltyList()
    (…Set/Map) top-level functions, and I wonder shouldn’t there be an equivalent like
    emptyMutableList()
    ?
    👍 1
    b
    r
    • 3
    • 4
  • j

    jw

    02/16/2018, 4:25 PM
    emptyList
    returns a singleton... semantics you shouldn't match with an
    emptyMutableList
    i
    • 2
    • 1
  • n

    natpryce

    02/16/2018, 4:37 PM
    We’ve encountered an ambiguity: we have a function that is overloaded for Int and Long. If we call it with a literal, the compiler doesn’t know which overload to call. We can use the “L” suffix to give the literal the Long type. But there’s no syntax for giving a literal the Int type. How about an I or i prefix for Ints?
    l
    • 2
    • 1
  • b

    benleggiero

    02/19/2018, 4:21 AM
    I’d like to revisit Implicit Member Expressions for a moment. One reason it was shot down was because Kotlin nearly emulates this with static `import`s. However, something a language with IMEs can do that Kotlin cannot is handle members with identical names. For instance, Kotlin gives several errors for this:
    import Foo.*
    import Bar.*
    
    
    enum class Foo {
        a,
        b,
        c
    }
    
    
    
    enum class Bar {
        a,
        b,
        c
    }
    
    
    
    fun translate(x: Foo): Bar = when (x) {
        b -> a
        a -> b
        c -> c
    }
    
    
    val fooBar = translate(a)
    Error:(21, 30) Kotlin: 'when' expression must be exhaustive, add necessary 'a', 'b', 'c' branches or 'else' branch instead
    Error:(22, 5) Kotlin: Unresolved reference: b
    Error:(22, 10) Kotlin: Unresolved reference: a
    Error:(23, 5) Kotlin: Unresolved reference: a
    Error:(23, 10) Kotlin: Unresolved reference: b
    Error:(24, 5) Kotlin: Unresolved reference: c
    Error:(24, 10) Kotlin: Unresolved reference: c
    Error:(29, 24) Kotlin: Unresolved reference: a
    And the only way to resolve these is to say
    Foo.a
    or
    Bar.c
    everwhere a member of either is needed. With proper IME support,
    .a
    and
    .c
    would do the job every time without ambiguity.
    ➕ 1
    g
    • 2
    • 2
  • m

    mikehearn

    02/19/2018, 4:44 PM
    Can I suggest for solving https://youtrack.jetbrains.com/issue/KT-19289 (a java interop issue) that Kotlin's behaviour when faced with ambiguous annotations is changed to be more promiscuous? Quite a few frameworks end up being uglier to use than necessary because Kotlin picks a single thing to attach the annotations to, instead of just attaching them everywhere.
    ➕ 1
    g
    • 2
    • 1
  • g

    groostav

    02/24/2018, 9:05 PM
    was there ever any discussion about having borrow semantics like rust's in kotlin?
    r
    j
    • 3
    • 11
  • p

    Pere Casafont

    02/26/2018, 3:06 AM
    the only thing I miss from kt is real immutability like cpp's; in there, if some object is const, you can only read its fields and call only its const methods (which guarantees the object is not going to change)...but right now there's only "pointer" immutability. Any thoughts on that?
    r
    b
    +3
    • 6
    • 16
  • c

    cedric

    02/26/2018, 4:02 AM
    @Ruckus
    val
    is not what C++'
    const
    is
    r
    • 2
    • 2
  • p

    Pere Casafont

    02/26/2018, 8:46 AM
    now it's the other way around, the value immutability concept looks dead in modern languages 😞
    b
    c
    • 3
    • 2
  • p

    Pere Casafont

    03/03/2018, 6:24 PM
    I've given some thought to it and it may be cool to add thread safety to this by implicitly creating readonly locks on objects when passed as "const"
    a
    • 2
    • 16
  • a

    Aregev2

    03/05/2018, 5:51 AM
    Started to learn kotlin for Jvm and native and I got few suggestions for language improvement (few methods that will make the life easier) https://gist.github.com/d8c5d702e7e23e05a55b5ec9376383be Thank you for an amazing language that keeps growing Alon Regev
    👍 2
    😁 2
    :youtrack: 1
    g
    s
    k
    • 4
    • 20
  • k

    karelpeeters

    03/11/2018, 12:39 AM
    @diesieben07 As a workaround you can "pass" those generic parameters to the typealias:
    typealias Complicated<T, E> = List<Pair<T, List<E>>
    d
    • 2
    • 4
  • s

    sanf0rd

    03/12/2018, 2:52 PM
    Hei guys, how about enum type inference. I mean kotlin compiler would infer what enum type it is and just expect .ENUM_NAME. This feature would clean a lot when expressions with enuns.
    e
    • 2
    • 1
  • b

    benleggiero

    03/12/2018, 3:25 PM
    I just posted this last month...
    r
    • 2
    • 2
  • d

    diesieben07

    03/12/2018, 3:46 PM
    Oh, you want it for more than
    when
    ?
    b
    • 2
    • 1
Powered by Linen
Title
d

diesieben07

03/12/2018, 3:46 PM
Oh, you want it for more than
when
?
b

benleggiero

03/12/2018, 3:56 PM
Well yeah... Anywhere the type is already known. Function parameters, variable assignment, turn statements, etc
View count: 2