SDGGiesbrecht
February 2, 2019, 8:28pm
2
Your observations are all astute and your writing style is refreshingly concise. It is great to have someone like you bringing valuable feedback.
Many of these are being discussed in other threads. Posting more specifically about each topic in its own thread would make it more likely that those designing, implementing or just petitioning for the those things will hear what you have to say. If they are already focused on something, they are less likely to take the time to read new threads with unspecific titles. There is certainly value to having a general overview somewhere, so thank you for this. But you are more likely to push things forward by posting in the existing threads. Everyone who has already posted in an existing thread or spent a lot of time reading it will receive a notification of your response, even if nothing new had been posted to that thread in a long time. But brand‐new threads like this one will only be seen by those who aimlessly peruse the “latest” section on the home page or who have actively registered to track the general subject—and even then you are relying on the title to catch their interest, because that is all they will see until after they have decided whether or not to click.
These threads may interest you:
rsebbe:
Fixed-size arrays.
To better support interfacing with lower level systems, like graphics
libraries for example, it would be helpful to support the concept of
contiguous variables. The most common use case for this would be to create
a Matrix struct that can be passed as data into something like Metal. This
can be accomplished now, using something like the following:
Current Option 1:
struct Matrix2x2 {
var m00: Float
var m01: Float
var m10: Float
var m11: Float
}
OR
Current Option 2:
s…
rsebbe:
Improved access levels.
Why not add a scope which allows access to the variables and functions only for the type itself and its extensions, but only within the current module? This would result in limitation of visibility from the outside (the same way private does) except for the fact that extensions could actually change these variables/functions. Also, restricting it to the module at the same time would not allow access to them and doing extensions like xWrapper (mentioned in one of the mails), unless it was in the …
rsebbe:
Namespaces
As is well known,, i am not the biggest fan of adding the namespace keyword to the language solely so we can have namespaces in Swift. however! I am a big proponent of submodules and I just had an idea of how we can combine the two concepts and get two features with one keyword.
Right now, Swift has modules which have the concept of binary compatibility and distribution, and are equivalent to what other languages call packages. Modules are great for distributing full libraries and applications.…
rsebbe:
Module import/re-export rules
I told @Jon_Shier I'd write something up on @_exported and visibility in general, so here it is. It's a bit of a brain dump, but I know if I wait until I have time to edit it it won't get posted for months. (That's already true, in fact; I've had this model kicking around my head for probably close to a year now.) So, thanks for the prompt, Jon.
Today, if your Swift library "Foo" uses a library "Bar", the headers (or swiftmodule files) of "Bar" must be available to all clients of "Foo". This i…
rsebbe:
Better interface readability.
As you can probably tell, I've been saving a lot of discussions, waiting for Swift 4.2 to be in a pretty good place before we jump all in on Swift 5. This one's one of the main things I plan to be working on in the next year or so, so I wanted to make sure you all had the big picture. It is another massive Jordan Rose post, so if you want the TLDR, just read the bolded sentences in each section and then jump down to the plan at the end. Thanks!
rsebbe:
Bridging headers.
I don’t see anything related yet. You could start a specific thread.
rsebbe:
The if case let (or is it if let case , already forgot…) syntax is very hard to remember, and requires an if block when there are associated values.
It would be nice if you could compare an enum without its associated values i.e a case equality check only rather than case & associated value equality check.
For example:
enum Foo {
case bar(Int, String)
}
let test: Foo = .bar(1, "Hello")
let isEqualWithItsAssocValues = test == .bar(1, "Hello") // true
let isEqualWithoutItsAssocValues = test == .bar(_, _) // also true
This makes it really easy to compare enums if you only care about the case and not its associated values and you wouldn…
rsebbe:
Edge-case access level behaviors.
That is probably worth a bug report: bugs.swift.org
rsebbe:
There are some strange syntax elements, like the comma in if let x = xxx, x.a == true .
rsebbe:
About nested funcs, the dependency on self (strong reference) is hidden, which is sometimes misleading.
I don’t see anything related to either of these yet. You could start specific threads.
rsebbe:
Asynchronous programming (async/await, or even better).
There are a lot of threads about different aspects: Search results for 'async' - Swift Forums
Chris Lattner’s concurrency manifesto and his draft proposal for async and await might also interest you if you plan on joining the discussion:
async_swift_proposal.md
# Async/Await for Swift
* Proposal: SE-XXXX
* Authors: [Chris Lattner](https://github.com/lattner), [Joe Groff](https://github.com/jckarter)
## Introduction
Modern Cocoa development involves a lot of asynchronous programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.
This paper introduces a first class [Coroutine model](https://en.wikipedia.org/wiki/Coroutine) to Swift. Functions can opt into to being *async*, allowing the programmer to compose complex logic involving asynchronous operations, leaving the compiler in charge of producing the necessary closures and state machines to implement that logic.show original
8 Likes