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

    Niko

    12/29/2021, 12:27 PM
    I was reading the stdlib docs on StateFlow, and began to wonder: as stdlib docs often have vast documentation with what, when, and often how (+ additional dokka
    @sample
    annotations) I began to wonder: Almost nothing is as bad as public API being documented wrong: old information, deprecated behaviour, bugs in the code having invalid/unexpected behaviour. This is mostly about compiler+dokka/kdoc, but would it be feasible to offer an additional
    @proof path.to.Test.withProofOfBehaviour
    attached to kdoc paragraph, that at compile time/in IDE after changes to source would be checked (run using the test runner, like
    git bisect
    ) and show the doc with red squiggly if doc proof didn't pass?
    h
    2 replies · 2 participants
  • x

    xxfast

    01/03/2022, 11:16 PM
    Not sure if this is mentioned elsewhere, but why does `class`es have their templates declared after their name, whereas `fun`ctions have their templates declared before their name? shouldn’t they follow the same notation?
    fun <T> Foo(bar: T) = Unit
    class <T> Bar(foo: T) // wont compile
    or
    fun Foo<T>(bar: T) = Unit // wont compile
    class Bar<T>(foo: T)
    j
    d
    +2
    7 replies · 5 participants
  • a

    Arun

    01/12/2022, 11:27 PM
    Does Kotlin have UFCS? https://en.m.wikipedia.org/wiki/Uniform_Function_Call_Syntax I didn't find any related documentation. What would it take to support UFCS?
    h
    m
    +2
    8 replies · 5 participants
  • r

    Rescribet

    01/15/2022, 5:02 PM
    I was looking at the KT-43871 concerns section, which reminded me of what I originally thought the
    to
    method was for. A method (or pair) to let the compiler automatically wire type conversions:
    // I'm not well versed in Kotlin interfaces
    interface Convertible<reified A : Any, reified B : Any> {
        inline fun from<A>(val it: A): B
        inline fun <http://A.to|A.to><B>(): B
    }
    
    // or more explicit
    convert fun A.B(val it: B): A
    data class Point(val x: Int, val y: Int)
    
    /** Creates a Point from an IntArray */
    fun Point.from<IntArray>(val it: IntArray) = Point(it[0], it[1])
    fun <http://Point.to|Point.to><IntArray>() = intArrayOf(this.x, this.y)
    
    fun draw(point: Point)
    
    draw(Point(0, 1))
    draw(listOf(0, 1) -> draw(Point(it[0], it[1]))
    Where the compiler will check the existence of a matching conversion and apply it automatically. Note that it should only be added by developers on types with clear semantics, e.g. String should be avoided in most use cases. Adding inline classes for more specific behaviour might be helpful (i.e.
    HumanReadableString
    and
    SerializableString
    ) Other use-cases: • Java interop,
    <http://java.time.Instant.to|java.time.Instant.to><kotlinx.datetime.Instant>()
    • Serialization, ie
    MyClass.from<String>()
    • Automatic API upgrades,
    <http://V1Object.to|V1Object.to><V2Object>()
    e
    1 reply · 2 participants
  • h

    hfhbd

    01/26/2022, 3:05 PM
    I really like named arguments. So how about named generics? With classes/functions with more than 1 generic and consume the class/functions, named generics would improve readability, especially when some generics parameters contains
    Unit
    or
    Nothing
    . Usecase: A generic
    Converter
    interface:
    interface Converter<Input: Any, Output: Any> {
        fun convert(input: Input?): Output?
    }
    
    // normal (old) usage
    class StringToIntConverter: Converter<String, Int> {
        override fun convert(input: String?) = input?.toIntOrNull()
    }
    But sometime, you need to adopt the usage, because you always return a value unrelated to its inputs or simple log and fail:
    class FixedIntConverter(val unrelatedReturnValue: Int): Converter<Nothing, Int> {
        override fun convert(input: Nothing?) = unrelatedReturnValue
    }
    
    class IgnoreConverter: Converter<Int, Nothing> {
        override fun convert(input: Int?) = error("$input")
    }
    To understand, which
    Nothing
    matches to which generic type, you have to read the interface declaration. With named generics, you don't have to look up the declaration, because it is understandable by its name. This is also very useful, when you can't simple go to the declaration without any tools, eg in the GitHub PR diff view..
    class FixedIntConverter(val unrelatedReturnValue: Int): Converter<Input=Nothing, Int> {
        override fun convert(input: Nothing?) = unrelatedReturnValue
    }
    
    class IgnoreConverter: Converter<Int, Output=Nothing> {
        override fun convert(input: Int?) = error("$input")
    }
    Like named arguments, the same rules and behavior should apply, so naming is optional.
    i
    3 replies · 2 participants
  • s

    smallufo

    02/14/2022, 1:53 PM
    Hi , is it possible to build a
    inline class
    pool that returns same reference ? Related link : https://kotlinlang.slack.com/archives/C0B8Q383C/p1644805562640269 Play ground : https://pl.kotl.in/uBVYwgQgO?theme=darcula I am building a carousel-like Int , naming 
    Three
     , which restrict any Int value to 
    1..3
     . That is 
    Three.of(1) == Three.of(4)
     ,  
    Three.of(0) == Three.of(3)
       . I use a prebuild  array to simulate caching , hoping they get the same reference
    private val array by lazy {
      arrayOf(Three(1), Three(2), Three(3))
    }
    But it seems it doesn't work. When comparing reference 
    ===
     , it complains 
    Identity equality for arguments of types Three and Three is forbidden
     , which is counter-intuitive .
    r
    y
    4 replies · 3 participants
  • w

    Wyatt Kennedy

    02/15/2022, 5:51 AM
    I was wondering if value object declarations have ever been discussed within kotlin? My bad if I'm beating a dead horse somewhere. I've discussed this a few times over the years with coworkers about garbage collected languages and the answer is always, "If you need control over memory locality, you're using the wrong language," but that just seems like an incomplete answer. I'd like to discuss more technically what prevents this type of control, because I'm not super involved in the development of garbage collectors and don't quite understand the technical limitation or the desire to avoid value types. Why must languages with a clean syntax and languages with control of memory locality be mutually exclusive? What I'm proposing is the ability to declare that a real property for an Object (not a primitive) within a class is actually not a reference and is instead expanded as part of the class within memory like in other static compiled languages. Obviously, this is to reduce heap allocations and garbage collections and to improve cpu cache performance in places where performance is critical. This could just be a keyword or symbol applied at the declaration site of a property. Here is some possible syntax and the semantics for what I'm proposing:
    class TestInnerClass {
        var x : Float = 0f
        var y : Float = 0f
    }
    
    class TestClass {
        val bar : TestInnerClass! // the exclamation point makes it a value property declaration. Initialization rules are the same as type TestInnerClass
        var bar2 : TestInnerClass! // ERROR : value types cannot be mutable, since they aren't references
    }
    
    fun semanticExamples() {
        val foo = TestClass()
        foo.bar.x = 6f
    
        val test : TestInnerClass! = foo.bar // FINE: When used on a function local variable, TestInnerClass! is essentially a const ref in c++
        // when compiled, all usages of test can be replaced by foo.bar.
    
        val test2 : TestInnerClass = foo.bar // ERROR references of this type can be assigned elsewhere, would allow undefined behavior when foo is destroyed.
        val test3 : TestInnerClass? = foo.bar // ERROR same as above as well as not being able to be a nullable reference
        
        val foo2 = TestClass()
        foo.bar = foo2.bar // ERROR: value properties cannot be assigned because they are not references and implicit copy constructors do not exist
    
        takesTestInnerClassRef(foo.bar)
        functionTypeExample {
            foo.bar.x = 6f // the value type can still be referenced because the reference to foo is enclosed.
            test.x = 6f // ERROR: cannot be sure that the owner of test hasn't been garbage collected
        }
    }
    
    // Types TestInnerClass and TestInnerClass? are demotable to TestInnerClass! which is least permissive
    // The value type "!" annotates that the reference cannot be assigned to anything.
    fun takesTestInnerClassRef(testInnerClass: TestInnerClass!) {
        val test : TestInnerClass! = testInnerClass // still valid because they are basically just const refs
    
        val foo2 = TestClass()
        foo2.bar = testInnerClass // Error: value properties cannot be assigned to as mentioned above
    }
    
    fun functionTypeExample(func: () -> Unit) {
    }
    Most of these are simple semantic rules in the type system, the only compile issue being able to use indirection in JVM without a reference being managed by the garbage collector, (not sure if it doesn't already support this). This syntax being purely ad-hoc discourages it's use unless someone explicitly needs better control of memory locality for high performance sections. If you also introduced a value generic, you could also use this for compile time fixed length arrays of value objects should people want them.
    //   a way to declare value generics, I'm sure this has been discussed elsewhere
    //                          |
    //                          v
    class FixedArray<T : Any!, val Length : Int> {
        // ...
    }
    
    class Test {
        var x : Float = 0f
        var y : Float = 0f
    }
    
    fun valueArrayTest() {
        val foo = FixedArray<Test!, 6>()
    }
    While the semantic rules could apply to all compilation targets, (JS, JVM, Native, etc), you could just provide a warning that value annotations will be ignored in environments where it's simply not possible to enforce, (probably JS). Is any/all of this something that has already been made permanently off the table?
    i
    m
    6 replies · 3 participants
  • j

    janvladimirmostert

    02/25/2022, 7:47 AM
    Proposal: A mechanism to extract variables from Strings converting Strings to StringTemplates at compile time Example:
    val foo = """
    Hello World from ${firstName} ${lastName}
    """.toTemplate()
    foo
    now contains a StringTemplate which contains a list of variables, firstName and lastName as well as parts of the String:
    ["Hello World from ", firstName, " ", lastName, "\n"]
    Use case 1 on the JVM, SQL queries:
    val simpleQuery = """
    SELECT a, b, c FROM table WHERE foo = $value1 AND bar = ${value2 + 1}
    """.toTemplate()
    by doing a toTemplate() and replacing all variables directly with ?, you avoid SQL injection attacks while also simplifying having to track how many
    ?
    you've added to the String and how many values you need to provide (especially when building more complex queries that requires concatenating clauses depending on what filters are switched on). If a SQL driver now only accepts a StringTemplate instead of a String for a query, there's very little chance of a dodgy value slipping into the SQL query via ${dodogyValue} whereas there's no way currently to stop someone from putting variables directly into a String and potentially opening a SQL Injection attack vector. Use case 2 that spans JVM + JS:
    val html = """
    <html>
      <head>
        ...
      </head>
      <body>
        Hello World from $firstName $lastName
      </body>
    </html>
    """.toTemplate()
    This now allows me to serve that HTML server-side with firstName and lastName already filled in (great for building sites that requires SEO)
    <html>
      <head>
        ...
      </head>
      <body>
        Hello World from Piet Venter
      </body>
    </html>
    but I can also generate a JavaScript ES6 String Template that can be re-used on the web to re-render the DOM if one of those values change client-side:
    let template = `<html>
      <head>
        ...
      </head>
      <body>
        Hello World from ${firstName} ${lastName}
      </body>
    </html>`;
    This ES6 template way of doing things is being used by frameworks such as uhtml, lit-html, lit-element and many more and if you're using those with a JVM backend, there's no easy way to get server-side rendering without writing the templates twice, once for backend rendering and once for client rendering. Isomorphic applications with such ES6 frameworks are only supported with a JavaScript backend; with a String.toTemplate() compile-time helper, it becomes possible to build those templates in a Multiplatform way that can be used for the initial server-side rendering and then re-using those templates client-side. XSS attacks can also be mitigated by stripping the ${} from the String and allowing the framework to escape anything that could be considered dangerous and using the positions array to insert those strings before rendering it.
    val securedString = stringTemplate.mapIndexed { index, part -> if (index.isEven()) part else escape(part.toString()) }.joinToString()
    Use case 3: Building re-usable templates that can be used with other services Something like MailChimp might want you to use %value for variables while SendGrid might want a different format for sending emails. I can now re-use my StringTemplate and create extension functions to convert these StringTemplates to something that other services might want to use, StringTemplate.toMailChimpFormat() or StringTemplate.toSendGridFormat() Or if you are sending an email locally where you have all the data, you can just fill in those variables yourself to convert that StringTemplate to a String again. Suggested data format for StringTemplate: StringTemplate can be as simple as a value class that contains the String parts and Value parts all mixed together:
    @JvmInline
    value class StringTemplate(private val value: List<Any?>)
    Considerations: 1: Doing
    """    ...    """.trimIndent().toTemplate()
    should trim the indent without replacing the template variables after which toTemplate() gets to strip the template variables 2: StringTemplate + StringTemplate should concatenate their individual lists of String parts and Values which would return a new StringTemplate with Strings and Values combined 3: It might be beneficial to adjust Dukat to convert tag-functions from JavaScript into regular Kotlin functions that takes a StringTemplate as param instead of the vararg thing it currently generates that's not really usable in KotlinJS 4: toString() can concatenate all the String parts and values to return a value as if it was never broken up. 5: Other platforms: since StringTemplate is just a List<Any?>, it shouldn't be an issue when interopting with other languages 6: String + StringTemplate should not be allowed and instead it should be encouraged to either explicitly convert String.toTemplate() or StringTemplate.toString() unless somebody explicitly overrides the plus operator to allow this. 7: Shorthand: instead of writing toTemplate() everywhere, maybe there's a nicer way to accomplish this, maybe we can use the Spread Operator here,
    *" My String Template ${...} "
    // converts this to a StringTemplate at compile time 8: Considering that we'll need to distinguish between what is a static String and what is a Value, there are two approaches here 8.1: wrap Strings and Values with some value class (personally I think this is unnecessary) 8.2: When splitting the String, make sure that it's always following the format String, Value, String, Value, String, ...
    """ Hello $foo$bar """
    would then split to
    [" Hello ", foo, "", bar, " "]
    which means two variables that are next to each other will be separated with an empty string and the beginning and end of the list of values will always be a String even if it's an empty String 9: Value classes would solve the "proper escaping of expressions" ticket,
    value class HTML(val template: StringTemplate)
    , but this can be implemented by each framework separately and should not be part of the standard library. Inside the value class, the toString can be overwritten which can then call the correct escape function
    fun toString() = template.mapIndexed { index, part -> if (index.isEven()) part else htmlEscape(part.toString()) }.joinToString()
    val safeHTML: String = HTML("""
      <strong>$foo</strong>$bar
    """).toString()
    EDIT: submitted this in YouTrack https://youtrack.jetbrains.com/issue/KT-51481
    👍 1
    e
    j
    11 replies · 3 participants
  • d

    Derek Peirce

    02/26/2022, 4:27 AM
    Is there any plan for implementing compile-time reflection, at least at a basic level? I've asked about it here before, but recently I've been running into more places where I want to pass, for example, both a getter and setter for a property into a method, and this would be burdensome:
    applyMutation({ x }, { x = it })
    I would much rather be able to pass in the property to the inline method, and have the getter and setter be derived from it automatically when inlining:
    applyMutation(::x)
    but we currently instead end up with terribly inefficient (compared to direct accesses) `KMutableProperty0`s.
    👍 1
    j
    e
    +1
    7 replies · 4 participants
  • m

    Mina Racic

    02/27/2022, 10:27 AM
    Hi all, Please take a look at this new feature proposal. How it looks to you?
    d
    h
    +2
    11 replies · 5 participants
  • l

    lhwdev

    03/05/2022, 3:34 AM
    I came up to think that something like explicit abstract would be really helpful for api authors, even though I do not really have a usecase. When one add new abstract member to super class, if child class is not abstract, it would lead to errors. For example: there is
    interface Super {
      fun a()
    }
    And
    class Child : Super {
      override fun a() { TODO() }
    }
    If we add new member to
    Super
    , it will cause a compiler error to
    Child
    . What I want is, to have a same behavior(compiler error) even if
    Child
    is abstract class. So I need to explicitly implement all abstract members like:
    interface Super {
      fun a()
      fun b() // new
    }
    
    @ExplicitAbstract
    abstract class Child : Super {
      override fun a() { TODO() }
    
      // if this is absent, would lead to compilation error
      override abstract fun b() // if cannot implement here, mark as abstract
    }
    Note that I didn't think about how to mark it(here,
    @ExplicitAbstract
    ) so don't care. Honestly, this is just an idea and I don't know if it would be useful. What do you think?
    r
    4 replies · 2 participants
  • t

    therealbluepandabear

    03/13/2022, 11:25 PM
    Will Kotlin ever add support for 2 dimensional arrays, if not, why? I feel as though 2 dimensional arrays are a good feature that most other programming languages have.
    s
    b
    +2
    4 replies · 5 participants
  • m

    Mikhail

    03/30/2022, 2:14 PM
    is it possible to make operator overloading for this? Like, I always need to use
    toTypedArray
    every time i want to translate the list to variable length argument. For example:
    operator fun <T> whatever(list: List<T>): Array<out T> = list.toTypedArray()
    j
    2 replies · 2 participants
  • s

    stantronic

    03/30/2022, 5:20 PM
    Hi 🙂 Can anyone tell me where I can find the proposal/ticket is for a “namespace” feature? Is this something still being entertained?
    m
    2 replies · 2 participants
  • l

    LastExceed

    04/01/2022, 6:48 AM
    allow overriding functions to have additional parameters with default values
    interface I {
    	fun foo(x: Int)
    }
    
    class C : I {
    	override fun foo(x: Int, y: Int = 0) {}
    }
    basically sugar for
    override fun foo(x: Int) = foo(x, 0)
    fun foo(x: Int, y: Int) {}
    t
    m
    +2
    13 replies · 5 participants
  • m

    Mikhail

    04/02/2022, 8:54 PM
    automatic detection of type parameters?
    e
    3 replies · 2 participants
  • e

    Exerosis

    04/09/2022, 3:28 PM
    Probably already been proposed but "private inheritance":
    interface Foo
    class MyClass : private Foo
    Unless I'm missing something it's more memory efficient than dedicating a private/protected field to an instance of Foo to be used internally.
    l
    g
    +1
    19 replies · 4 participants
  • m

    Michael de Kaste

    04/11/2022, 9:31 AM
    More ranges: other than the standard
    [a..b]
    we get with the
    ..
    constructor (and even the
    until
    keyword, which is still a
    [a..b]
    range. They don't need to be progressions.
    g
    k
    8 replies · 3 participants
  • s

    Sam Stone

    04/12/2022, 5:39 PM
    I feel that interfaces should support default values for `var`s which implementers can optionally override. I have a
    FilterableListAdapter
    that keeps track of what the previous search was, whether the user initiated a search or it was from the system, etc. I am going to initialize those values to false/empty string on every single implementor, and it just becomes boilerplate to do so. If the interface could define them, classes would be much cleaner and focused on what makes them unique.
    y
    p
    +1
    18 replies · 4 participants
  • s

    Sam Stone

    04/12/2022, 11:05 PM
    Made a lazy
    Iterable<A>.zip(Iterable<B>)
    version similar to
    Iterable.withIndex()
    that returns an
    Iterable<Pair<A, B>>
    instead of what
    withIndex()
    returns (viz.
    Iterable<Pair<T, Int>
    ). I called it
    Iterable.with(Iterable): ZippingIterable
    (instead of
    IndexingIterable
    for
    withIndex()
    ). It seems like a natural corollary to
    withIndex()
    and a common enough use case (viz. two Iterables, want to zip like
    zip
    but want it lazy like
    withIndex
    ). Thoughts?
    e
    5 replies · 2 participants
  • s

    Saiedmomen

    04/15/2022, 7:28 AM
    Is there a KEEP or youtrack issue for adding the capturing subjects feature that
    when
    has, to more(or all) language control flows?
    when (val response = executeRequest()) {
                ...
            }
    https://kotlinlang.org/docs/control-flow.html#when-expression
    d
    h
    +1
    6 replies · 4 participants
  • t

    twisterrob

    04/22/2022, 5:11 PM
    Probably not the right place, but wanted to start somewhere. I imagine an alternate universe where Kotlin versions follow semantic versioning in
    <major>.<minor>.<patch>
    form so updates could be automated by scripts (Renovatebot/dependeabot) with ease. The current
    1.<major>.<minor><patch>
    format is hard to parse and also not even correct since theoretically there was no major breaking change yet (that is if you ignore the deprecated/removed methods, renamed command line flags, incubation/optin features, compiler backend change, Gradle DSL changes, and tons of warnings etc.). Is there a proposal for doing the "Java maneuver" and going from 1.6 to 7.0 next release?
    ☝️ 2
    e
    4 replies · 2 participants
  • e

    ephemient

    04/27/2022, 6:32 AM
    can the https://kotlinlang.org/docs/reference/grammar.html rule for
    ifExpression
    be changed from
    'if' '(' expression ')' (controlStructureBody | (controlStructureBody? ';'? 'else' (controlStructureBody | ';')) | ';')
    to
    'if' '(' expression ')' (controlStructureBody | (controlStructureBody? ';'? 'else' (ifExpression | controlStructureBody | ';')) | ';')
    or some other equivalent change, to make
    if (…) { … } else if (…) { … } else { … } ?: …
    parse like
    (if (…) { … } else if (…) { … } else { … }) ?: …
    rather than the current unintuitive
    if (…) { … } else (if (…) { … } else { … } ?: …)
    ?
    d
    3 replies · 2 participants
  • r

    Rob Elliot

    04/28/2022, 10:14 PM
    Probably a pipe dream, but it would be nice if there were a mechanism to make a `data class`'s
    copy
    method delegate to an
    operator fun invoke
    on the class's
    companion object
    that took the same parameters but was able to return a more flexible return type. It's a shame that you have to put all the invariant checking in the data class's
    init
    , and so have to fail it with exceptions.
    h
    5 replies · 2 participants
  • s

    Sebastian Brunner

    05/05/2022, 12:22 PM
    I was just wondering if there's currently a KEEP for adding support for non-exhaustive enums. I recently discovered this in Rust and I think it's really useful for enum classes that aren't finished yet and more enums will follow (a good example might be error codes). I'm imagining an annotation
    @NonExhaustive
    which forces you to define an
    else
    branch even if you cover all enums in your when clause. See Rust docs: https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute Here's their original RFC from 2008: https://github.com/rust-lang/rfcs/blob/master/text/2008-non-exhaustive.md
    j
    o
    +1
    4 replies · 4 participants
  • b

    BVG

    05/06/2022, 2:14 PM
    Hi everyone! I'm not sure this problem was raised before. I assume it must be a pretty common case, but found no links to discussions. *TL;DR*; it'd be nice to have "smart" exhaustive when statement over sealed types, which would take its generics into the account. Here's an example:
    sealed interface SealedOf<Type>
    
    object SealedOfString1 : SealedOf<String>
    object SealedOfString2 : SealedOf<String>
    
    object SealedOfInt1 : SealedOf<Int>
    object SealedOfInt2 : SealedOf<Int>
    
    fun theIssue() {
    
        // Note that variable restricts the values only to SealedOf<String>
        var subject : SealedOf<String> = SealedOfString1
    
        // This is the only way to have exhaustive when statement - and it produces a compilation error:
        // Incompatible types: SealedOfInt1 and SealedOf<String>
        when (subject) {
            SealedOfString1 -> TODO()
            SealedOfString2 -> TODO()
            SealedOfInt1 -> TODO()
            SealedOfInt2 -> TODO()
        }
    
        // This produces warning or error:
        // Non exhaustive 'when' statements on sealed class/interface will be prohibited in 1.7,
        // add 'SealedOfInt1', 'SealedOfInt2' branches or 'else' branch instead
        when (subject) {
            SealedOfString1 -> TODO()
            SealedOfString2 -> TODO()
        }
    }
    It'd be nice for compiler to understand that
    SealedOf<Int>
    types cannot be assigned to the variable, and therefore no
    SealedOfInt1, SealedOfInt2
    branches are needed. Writing
    else
    branch resolves the compilation error, but that is not why sealed types are used 🙂
    👍 1
    h
    r
    5 replies · 3 participants
  • x

    xxfast

    05/07/2022, 1:23 PM
    val funtionType: (index: Int) -> Unit
    
    functionType(index = 1) // Named arguments are not allowed for function types
    is there a reason why it is not allowed?
    ➕ 1
    m
    1 reply · 2 participants
  • m

    Mikhail

    05/11/2022, 10:19 AM
    huh? I don't see any reason why.. Although, I can move it to the top level
    p
    3 replies · 2 participants
  • m

    Mikhail

    05/11/2022, 4:05 PM
    wouldnt such a syntax be more convenient?
    val (first, second!!) = Pair<String, String?>("not null", "same")
    
    // so I dont have to:
    val (first, second) = Pair<String, String?>("not null", "same")
    // and then
    val secondNotNull = second!!
    f
    k
    +1
    10 replies · 4 participants
  • m

    Mikhail

    05/16/2022, 4:03 PM
    Why doesn't kotlin have a bit shift operator?
    k
    g
    3 replies · 3 participants
Powered by Linen
Title
m

Mikhail

05/16/2022, 4:03 PM
Why doesn't kotlin have a bit shift operator?
k

Klitos Kyriacou

05/16/2022, 4:06 PM
Is shl no good?
m

Mikhail

05/16/2022, 4:08 PM
By bitwise operators I mean those that Java, C++ and other languages have Kotlin's infix bitwise functions are fine.
g

gildor

05/18/2022, 7:17 AM
Please, check this channel description
View count: 2