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()
}

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.

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.

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

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

oh boy, here we go https://github.com/JetBrains/kotlin/commits/rr/zarechenskiy2

and what is example of context where it would helpful? I mean some code that an be improved using these extensions

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

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.

1b

can be confused with hexadecimal literal

There are other cases, where you must use toByte(): byteArrayOf(0xB0.toByte(), 0x7B.toByte(), 0x00.toByte())

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
    }
}

Where do you draw the line? Should

- other

and

in other

also work when leaving out

this

?

Why

y

for bytes? I skimmed the linked JDK proposal, couldn't really find any justification there either.

Is that a #stdlib proposal since it can be entirely done in annotations?

We have

emltyList()

(…Set/Map) top-level functions, and I wonder shouldn’t there be an equivalent like

emptyMutableList()

?

emptyList

returns a singleton... semantics you shouldn't match with an

emptyMutableList

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?

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.

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.

was there ever any discussion about having borrow semantics like rust's in kotlin?

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?

@Ruckus

val

is not what C++'

const

is

now it's the other way around, the value immutability concept looks dead in modern languages 😞

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"

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

@diesieben07 As a workaround you can "pass" those generic parameters to the typealias:

typealias Complicated<T, E> = List<Pair<T, List<E>>

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.

I just posted this last month...