KEEP VS swift-evolution

KEEP: Context receivers

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

This will be furthermore simplified with multiple receivers coming very soon

I’m realizing I forgot to mention the scripting proposal in the post, will add it soon.

Tfw no pattern matching. :(

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.

I'm aware that kotlin decided against this in kotlin itself, see https://github.com/Kotlin/KEEP/issues/82.

Swift has placeholder types as of 5.6, more about them here: https://github.com/apple/swift-evolution/blob/main/proposals...

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.

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

The commonly rejected proposals and the linked FAQ suggest that self-hosting Swift is not a priority at the moment.

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

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

Not yet--You're asking about SE-0309. This is one of the intermediate steps to that.