uli
10/14/2021, 8:09 PMsuspend
-edness is not inferred on functional receivers at call site.Hullaballoonatic
10/17/2021, 6:24 PMfun foo((x, y): Pair<Int, Int>) = // whatever
jimn
10/17/2021, 8:11 PMif (!buf.hasRemaining() || read == -1) createWriteNode(buf.flip()) else null
with
infix operator fun <T> Boolean.rem(s: T) = { s }.takeIf { this }?.invoke()
...
(!buf.hasRemaining() || read == -1) % createWriteNode(buf.flip())
to guarantee that s
doesn't fire before comparison?
i actually prefer
inline val <reified T> T.`⟲` get() = { this }
inline infix operator fun <reified T> Boolean.rem(s: T) = s.`⟲`.takeIf { this }?.invoke()
as the style matches the idioms i use in in prior art but i just don't quite find the langauge lawyer parts i need to trust bytebuffer ops to this one, it has worked for more mundane ternary targets leading up to this but bytebuffers have effectsHullaballoonatic
10/23/2021, 6:19 PMlouiscad
10/29/2021, 3:17 PMAndy Victors
11/08/2021, 8:13 PMclass Player : Listener<State> by ListenerBase<State>, Listener<Source> by ListenerBase<Source>
But why? Specified generic is a separate type to me. Why cannot I reuse one class for aggregation?ankushg
11/10/2021, 1:01 AMapiVersion
and languageVersion
like a maven artifact or Github Release?
I'm trying to set up a CI matrix to make sure we're compatible with the latest versions, but would like to avoid hardcoding them and somehow programatically fetch the latest ones where possibleElie Abichar
11/11/2021, 4:02 PMelect
11/23/2021, 8:49 AMNumber
). So I was thinking, maybe we can have inline classes exposes/extends/delegates specific interfaces/classes from the underlying value..
something like
inline class UInt(val i: Int) : Number by i
elect
12/01/2021, 2:06 PMval a = Vec3()
val b = (a + 1) / 2
a + 1
will generate another Vec3
and so will / 2
.
This normally isn't the end of the world, but in specific situations, such as real time 3d graphics, embedded devices, hotspots, etc etc this may be an issue.
Googling around for ideas, I saw that also @Aleksei Dievskii in its viktor had this burden to deal with.
So I was wondering if there might be some solution involving some new language paradigms or features..elect
12/15/2021, 2:24 PMit0, it1,..
CRamsan
01/13/2022, 11:00 PMKotlin Language Specification is still in progress and has experimental stability level, meaning no compatibility should be expected between even incremental releases, any functionality can be added, removed or changed without warning.
https://kotlinlang.org/spec/introduction.html#compatibility
What does this refer to when talking about being in experimental stability? Is this referring to the document itself?uli
02/04/2022, 10:52 PMinline fun <reified T: Fragment> replaceFragment(
name: String = T::class.java.name
)
Why do I need inline refied
in the signature?
I do understand that T.class.java can not work on an erased type but, If I understand correctly, kotlin would insert the default parameters at call site where the type information is readily available.
If I am not mistaken in my assumptions, I propose to lift the restriction on generic types for when they are used in default parameter definitions.edrd
02/09/2022, 3:50 PMclass Logging {
val logger = java.util.logging.Logger.getLogger("test")
}
context(Logging)
fun hello() {
<http://logger.info|logger.info>("Hello")
}
fun <C, R> within(ctx: C, call: context(C) () -> R): R = call(ctx)
fun main() {
within(Logging()) {
hello() // Error: No required context receiver found: Cxt { context(Logging) public fun hello(): kotlin.Unit defined [...]
}
}
Is this supposed to be this way or it's just something not yet implemented in the prototype version?carbaj0
02/12/2022, 6:47 PMrocketraman
02/18/2022, 5:48 PMbuildString
block: overkill for this scenario, and while performant, still some runtime overhead
• String concatenation: not visually appealing, runtime overhead
• some combination of raw strings with trimMargin
and removing newlines: runtime overhead
Thoughts?Hullaballoonatic
02/20/2022, 9:49 PMMendess
03/02/2022, 10:42 PMuntil
but the toString implementation prints as inclusive of both ends)Youssef Shoaib [MOD]
03/17/2022, 5:19 PMgetValue
and setValue
methods? Is it to do with how regular local properties have a weird "backing field" and so supporting that can get muddy when it comes to cross-thread references and all? or is there another piece to the puzzle? And if that's the case, why not allow references to local delegated properties? After all, their mechanics are near-identical to normal delegated properties.Ben Woodworth
03/17/2022, 7:43 PMx.is<String>()
x.isNot<String>()
x.as<String>()
x.asOrNull<String>()
For one I think it would make chaining nicer. There are definitely times when I do .let { it as String }
on its own line in the middle of a big chain of calls, and was tempted to wrote my own fun <T> Any?.as(): T
but got dissuaded when I need to write `.`as`<...>()`. Mostly just a curiosity though :)Youssef Shoaib [MOD]
03/19/2022, 3:09 PM@HidesMembers
in the future to work for more functions? And specifically, because I prototyped this in Kotlin 1.4 I think, can the resolution order for @HidesMembers
be fixed to work for member extension functions (I think when I tried to get it to work HidesMembers
only works for plain extension funs)? My use case is changing the behavior of functions like toString
. Consider the fp-style Show:
interface Show<T> {
@HidesMembers
fun T.toString(): String
}
object IntShow: Show<Int> {
@HidesMembers
override fun Int.toString() = "$this is an Integer"
}
// usage
with(IntShow){
println(5.toString())
}
but this can work for overriding any member function to explicitly change its behavior whenever a receiver is in context. I would wager that this isn't surprising to the user of a library because they explicitly opt-in by bringing a receiver in scope.
Could this ever be a kotlin feature or am I dreaming too much lol?stantronic
03/28/2022, 3:13 PMconst val rawString = """
this
is
a
raw string
""".trimIndent()
is currently an error. But could it be changed at compile time to the equivalent of
const val rawString = "this\nis\na\nraw string"
Youssef Shoaib [MOD]
04/12/2022, 10:39 AMTypeWrapper
that is passed to the lambda, effectively making all the receivers before it visible.
inline fun <A, B, C, R> withContexts(a: A, b: B, c: C, block: context(A, B, C) (TypeWrapper<C>) -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return block(a, b, c, TypeWrapper.IMPL)
}
sealed interface TypeWrapper<out A> {
object IMPL: TypeWrapper<Nothing>
}
(Psst: here's a function to generate those up to an arity of 25):
fun generateDeclarations(index: Int): String {
val alphabet = "BCDEFGHIJKLMNOPQSTUVWXYZ"
val letters = ("A" + alphabet.take(index)).toList()
val lastType = letters.last()
val types = letters.joinToString(", ")
val receivers = letters.joinToString(", ") { it.lowercase() }
val parameters = letters.joinToString(", ") { "${it.lowercase()}: $it" }
@Language("kotlin") val codeTemplate = """
inline fun <$types, R> withContexts($parameters, block: context($types) (TypeWrapper<$lastType>) -> R): R {
contract {
callsInPlace(block, InvocationKind.EXACTLY_ONCE)
}
return block($receivers, TypeWrapper.IMPL)
}
""".trimIndent()
return codeTemplate
}
Youssef Shoaib [MOD]
04/14/2022, 4:39 PMcontext(Hello, World) class Foo { ... }
) should be able to access those class's receivers.
Additionally, maybe the same behaviour can be applied to a context receiver that is a context class. Lemme explain with an example:
class Hello { fun hello(name: string) = TODO()
class World { val value = 42 )
context(Hello, World) class Foo
fun Foo.fooExtender() {
// I should be able to call this with no issues
hello(value)
}
context(Foo) fun doSomethingInFooContext() {
// I should be able to call this with no issues
hello(value)
}
If the behavior for the doSomethingInFooContext
is too surprising, maybe we can have a special keyword for it (i.e. propagate
or something), or, we can only allow Hello and World to propagate through if Foo is available as a normal receiver and not a context one (IMO this is surprising and unintuitive).
Something to think about though is that if this is implemented, it'll be best to treat those class contexts as a heirarchy level above the other contexts (e.g. resolution order should be Foo's contexts are "weaker" than foo itself) and I recall that such heirarichal behaviour was considered unintuitive before, but it seems like it could be a necessary evil if we want class contexts to work intuitivelySrSouza
04/14/2022, 8:40 PMcarbaj0
04/19/2022, 7:14 AMobject Dependency {
val dep1: String = "1"
}
val lambda: context(Dependency)() -> Unit = {
dep1
}
carbaj0
04/29/2022, 12:51 PMjava.lang.Exception: IR lowering failed at: ….
we will have to wait a little longer heheAyfri
05/05/2022, 6:00 PMYoussef Shoaib [MOD]
05/22/2022, 1:53 PM// Implementation really doesn't matter, neither do the specific collections.
context(Map<K, V>, Set<V>)
fun <K, V> K.checkInclusion(): Boolean = this@Map[this] in this@Set // Check if our key K has a value which is a member of a set of accepted values
context(Set<Int>, Set<String>, Map<List<String>, String>, Map<List<Int>, Int>) // The last receiver is not needed to reproduce
fun reproducer(){
listOf("hello", "world").checkInclusion() // Error: Multiple arguments applicable for context receiver
}
However, if I just let IntelliJ insert explicit type arguments based on what it has inferred, everything compiles successfully:
listOf("hello", "world").checkInclusion<List<String>, String>()
IntelliJ even greys out the type arguments, saying that they're redundant. Is this a bug? Should I file this?Mikhail
06/13/2022, 3:32 PM