I have watched a video about Swift where it’s explained that structs with just one basic type (numbers/string) is optimized away at compile time to be represented by just that basic type. This allows the creations of thin wrappers.

I have unfinished KEEP "Inline classes" which covers this simple scenario of single field type-safe alias with requirements (extension functions, cross-module visibility, Java non-visibility, etc), use cases and possible syntax constructions, @dmitry.petrov should I post it as a PR to KEEP so community could discuss it, find issues and solutions or it's something we should wait for?

Since it works at compile time it would work for those types for which you declare a

Reified

instance. For example:

package foo
interface Reified<A> {
    val selfClass: KClass<A>
}

package bar
object ReifiedString: Reified<String> {
    val selfClass: KClass<String> = String::class
}

import bar.ReifiedString

fooTC<String>() // compiles and returns String::class
fooTC<Int>() // Does not compile because the compiler can't find evidence of `Reified<Int>` imported in scope

There's a "library solution" for

typeOf<T>()

that will get you a generic JVM type, but it'd cost a class file for each call site at the moment. --- That's getKType from the gist above ;)

Type literals might actually require some special syntax:

Some::type

currently can resolve to a member reference for

Some.type

Would it be possible to have a plugin similar to all open and no-arg, but for void return types? That is to say, if a function has the signature

fun foo(): Unit

it'd become

void foo()

in Java rather than

Unit foo()

when given a particular annotation. I think it'd make calling Kotlin code from Java a bit more pleasant.

Was it on a public forum of some kind where I can follow discussion?

has there been any decent HKT proposal yet?

I know in Java, you get a warning if you do

@Contract(pure = true)

(an annotation from the Jetbrains annotation package), not sure if that works in Kotlin too?

I the panel last night Andrey made it should like he has reservations about implementation via delegation. Is there anywhere that discusses the reasoning for why it might be problematic? I tend to use it quite often in an attempt to reduce boilerplate around things like rx subscription management.

I'd like to keep the ball rolling with this one. Anyone here can advise as to what next steps looks like? Looks by the numbers in the PR description this could be a great lang feature welcomed by many users and it has already seen a lot of discussion and iterations over the original proposal. https://github.com/Kotlin/KEEP/pull/87

is there any proposal for compile-time checked regex literals like in Node?

doesnt work

Wouldn't that be the same as adding a

static

keyword but less clear?

Or maybe allow adding

@JvmStatic

to the companion object.

When calling Java functions that have multiple parameteres eligible for SAM conversion, from Kotlin we can either pass lambdas for all those parameters or none of them. See for example https://stackoverflow.com/q/46542037/1916449 This makes sense, because otherwise Kotlin would have to generate 2^k synthetic functions for a Java function with k SAM-typed parameters. Instead it just generates the two extreme ones. Given the convention that if the last argument of a function is a lambda, you can place it after parentheses, wouldn't it make sense to also generate a special third synthetic variant, that accepts a lambda for the last argument if it's a SAM type?

one small observation porting some c++ code: not having the possibility to have

valueChanged |= whatever()

introduced on kotlin side a bug,

whatever()

was never executed when

valueChanged == true

, (

valueChanged = valueChanged || whatever()

solved by flipping the or operands)

Hello, when writing an inline fun <reified T> like the following:

inline fun <reified T> logd(message: String) {

if (BuildConfig.DEBUG) {

Log.d(T::class.java.simpleName, message)

}

}

If used without a specified type, the compiler will complain:

logd("abandonAudioFocus() called") // type inference failed: Not enough information to infer parameter T in (...). Please specify explicitly.

To fix this we need to specify the type:

logd<PlayerManager>("abandonAudioFocus() called")

Wouldn’t it be convenient if the compiler would infer the type of the class this code is called in in this case? Maybe with a new inline keyword ?

Declaring defaults for generic type parameters - it’s a nice little feature I miss in Kotlin, e.g.:

interface Foo<T, U = Unit, V = Unit>

or even:

interface Foo<T, U = Unit, V = T>

This way, if you don’t care about some parameters, you could write:

class Bar : Foo<Int>

instead of:

class Bar : Foo<Int, Unit, Unit>

So far I’ve seen it in C++ and TypeScript, and it seems to work well. What do You think?

could an alternative syntax for raw string literal be considered? this is ugly:

str.replace(""""""", """\""""")

how about

str.replace(`"`, `\"`)

how about

fun main(args: Array<String>) {
    val str = "--\"--"
    println(str)
    println(str.replace("\"", "\\\""))
}

Claiming koltin is so concise, wouldn’t an `if?`statement qualify. So that one can write

if?(state?.isValid)

instead of

if(state?.isValid == true)

So when we have an if-statement of an nullable value we don’t have to explicitly declare the

== true

all the time.

Whether null counts as true or false depends on the context. If I have a nullable bool, I use the Elvis operator:`if (state?.isValid ?: false) ...` or

if (state?.isValid ?: true) ...

We should support Implicit Member Expressions. This is something I enjoy at work with Swift, and drastically reduces boilerplate: https://stackoverflow.com/questions/47023274/what-is-the-swift-syntax-bar-called

Hi, In an Android project, I want to make two methods that return a delegate, with one allowing nullable values, and the other not. It's for Fragment arguments. The idiomatic way would be to add 2MB to my app by using kotlin-reflect to check if the delegated property is nullable. Instead, I aim for the lightweight way, which makes me write two delegates, one for nullable values, another for non nullables. I wrote two functions

arg()

and

'arg?'()

(the single quotes being backticks, just Slack limitation), but the IDE says

?

is not allowed in identifiers in Android projects. So I added the

JvmName("argOfNullable")

, but the IDE still complains, and I assume the compiler will too. So, please, could you add the ability to apply the identifier restriction only on the JVM name in the nearest Kotlin release possible?

What is the differences between this and

static import

?

Proposal to restrict an extension function for a

typealias

to that explicit

typealias

. Even if the compiler later removes all type aliases they could (and should?) first be enforced.

typealias Degree = Double
typealias Radian = Double

fun Degree.toRadian():Radian = // Implementation
fun Radian.toDegree():Degree = // Implementation

fun run(degree:Degree) {
  // should only be able to call toRadian and not toDegree on this parameter.
  degree.toDegree()
}

I also observe that the go-to example of why dependent types are useful is always Vector<N>, but usually I don't want to specify exactly how many elements a list has in the type, but being able to express non-emptyness (wish English had a short word for this) would have been concretely useful.

Are there any operations that works on eg. a non-empty list that don't work on an empty one? I can only think of

list[0]

.