KEEP
swift-evolution
Our great sponsors
KEEP | swift-evolution | |
---|---|---|
40 | 73 | |
2,623 | 13,318 | |
2.9% | 1.0% | |
6.2 | 9.4 | |
about 1 month ago | 6 days ago | |
Markdown | ||
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
KEEP
-
Toying with Kotlin's context receivers
KEEP: Context receivers
-
Java record pattern matching in JDK 19
I'd be very interested in a comparison between scala 3 using/given and Kotlin new context receivers https://github.com/Kotlin/KEEP/blob/master/proposals/context...
- Why no one recommends the use of the standard library's Result class but a custom sealed class approach?
-
[Question][Kotlin] Dexter Runtime Permissions development has stopped, whats the alternative?
This will be furthermore simplified with multiple receivers coming very soon
-
Combining scripts and DSLs is Kotlin’s most underrated feature
I’m realizing I forgot to mention the scripting proposal in the post, will add it soon.
-
Java 20 looks like it may be one of the biggest updates in years
Tfw no pattern matching. :(
- Encapsulate successful or failed function execution
-
Preview of Kotlin 1.6.20 With Prototype of Context Receivers, Parallel Compilation on JVM, Incremental Compilation in JS
I hadn't gone over the Context Receivers design proposal until now (and still doing so, so take this with a grain of salt), but the use of what is seemingly a function call(but not) to define them seems like a bad choice. I'm sure there are design constraints that pushed this option forward, but it just seems really odd and out of place in the current Kotlin language design.
-
JSpecify: Express specifications (initially, just nullness properties) in a machine-readable way
I'm aware that kotlin decided against this in kotlin itself, see https://github.com/Kotlin/KEEP/issues/82.
- State of Valhalla
swift-evolution
- Why are Swift regexen comparatively nonergonomic?
-
Golang Diaries: Generics
Swift has placeholder types as of 5.6, more about them here: https://github.com/apple/swift-evolution/blob/main/proposals...
-
WWDC 2022 (Expectations)
Most likely SwiftUI 4.0 (hopefully with better navigation) and Swift 5.7 with SE-0345if let shorthand for shadowing an existing optional variable and SE-0341Opaque Parameter Declarations. I'm hoping for some sort of CoreData 2 but other than that I'm not sure as far as Swift is concerned.
-
Let’s say I was a Swift fanatic since is started but got frozen in time in 2016. I have now been woken up and want to return to my favourite language. What have I missed? What is still the same? How do you think as a Swift programmer in 2022 vs the past?
a myriad of Swift Package Manager improvements! (you can check 'em out here if you want: https://apple.github.io/swift-evolution/ in addition to the rest of the proposals)
Eliminate IndexDistance from Collection (use Int instead)
if let shorthand for shadowing an existing optional variable
-
Mobile UI in Rust?
The commonly rejected proposals and the linked FAQ suggest that self-hosting Swift is not a priority at the moment.
-
“Generic cannot be inferred” when there’s irrelevant code
Fortunately this limitation could be partially lifted in the near future with the acceptance of Swift Evolution Proposal 0326: Enable multi-statement closure parameter/result type inference
-
Structured Concurrency
I do not know of any case studies or examples. However, my own code could be considered non-trivial because it's a full build system, or will be.
After writing only enough to get it bootstrapped, I'm now going through and redoing a lot to make it use all structured concurrency. Nevertheless, I don't think it's useful as an example, or rather, it won't be useful once the transformation is done.
> It'd also be interesting to know if all of the behaviour that was expressed in the original structureless concurrency code could be ported across to structured concurrency, or if it was still necessary to use structureless concurrency in a few places as the corresponding behaviour was not expressible.
I have a firm belief that the equivalence of structured and unstructured concurrency is exactly the same as the equivalence of structured and unstructured programming. It has been proven that you can express any possible unstructured program as a structured program. [0] (There is a bit of controversy over the original proof, but as far as I can tell, it has been proven as long as multi-level loop breaks/continues exist. See [1]. This is one reason why my language will have multi-level breaks/continues.)
I personally believe that such a proof exists for structured vs. unstructured concurrency and that it just needs to be found. Part of that belief is founded on [2], which does an excellent job of showing how the `go` statement is really a multi-branch `goto` statement. Perhaps I'll try to discover the proof and write it in a blog post.
(As a first dirty attempt, imagine all of the possible ways you could have more than one concurrent thread of execution. It should be simple to show how to turn every possible use of a `go`-like statement into an opening of a threadset that launches two tasks and waits on them before continuing. I'm not sure how any way of splitting a thread of execution into more than one thread of execution could not possibly be simulated with that. I could be wrong, though.)
Oh, and I just found out that Swift has structured concurrency! [3] This is great! And I think it is the first mainstream programming language with it. I think this is awesome because it means that structured concurrency is going mainstream. I hope it helps structured concurrency win against async/await, which I believe is a poor model.
So if you want a case study, I'd watch the Swift community; someone is going to rewrite their code using structured concurrency and write a blog post about it.
[0]: https://en.wikipedia.org/wiki/Structured_program_theorem
[1]: http://www.cs.cornell.edu/~kozen/Papers/BohmJacopini.pdf
[2]: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
[3]: https://github.com/apple/swift-evolution/blob/main/proposals...
-
Swift 5.6 Released!
Not yet--You're asking about SE-0309. This is one of the intermediate steps to that.
What are some alternatives?
compose-jb - Compose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.
KorGE - KorGE Game Engine. Multiplatform Kotlin Game Engine
okio - A modern I/O library for Android, Java, and Kotlin Multiplatform.
kotlin-wrappers - Kotlin wrappers for popular JavaScript libraries
foundationdb - FoundationDB - the open source, distributed, transactional key-value store
async-await-WWDC21-blog-post
kotlinx-datetime - KotlinX multiplatform date/time library
swift - The Swift Programming Language
htmx - </> htmx - high power tools for HTML
swift-algorithms - Commonly used sequence and collection algorithms for Swift
PeopleInSpace - Minimal Kotlin Multiplatform project with SwiftUI, Jetpack Compose, Wear Compose, Compose for Desktop, Compose for Web and Kotlin/JS + React clients along with Ktor backend.
rsocket - RSocket Protocol Definition