Dictionary and Set Improvements in Swift 4.0
swift.org
swift.org
For example NSNotificationCenter, setting attributed strings, core data or fetching resources. Also the whole MVC ViewController lifecycle is full of optionals. A lot of people abandon using Storyboards just to have ViewControllers that have everything set up compile safe, don't use prepareForSegue to pass in variables and so on. But that means doing everything in code, which is inefficient for complicated one-off layouts.
You can't use an enum for the keys because it supports custom attributes (at least you can't without exposing a `.custom(name: String)` case, which would defeat the purpose). And the values can be different types (enums for underline styles, URLs for links, [NS|UI]Color for foreground colors, etc.). I think the `NSAttributedStringKey` box type is a good compromise.
Maybe I'm biased (the Cocoa text system is one of my favorite APIs, and NSAttributedString is at the top), but I'm really happy with the state of attributed strings in Swift 4 myself.
An enum wouldn't be so bad if it also would use the associated value. Would make it impossible to set the wrong value at least.
However, you can't (at least currently) add new cases to someone else's enum (the way you can add methods). So if I decided I wanted my own custom text attributes (which isn't uncommon), we're back to type-unsafe land. We'd need the original enum to have an extra attribute case, like this[1].
[0]https://pastebin.com/L1xPcueu [1]https://pastebin.com/h8Rp3Ajy
The following things should be improved to make storyboards more useful in teams:
* No more bullshit changes of 0.5px just by looking at the storyboard alone
* Compile time check for connected outlets and actions, allowing to set them without the ! or ?
* Constructable view controllers that always require you to init them in some kind of way, so you don't end up with optionals everywhere
* Reusable constants for colors, sizes etcetera. I want to simply state cellSpacing as a value for the constant of a constraint where cellSpacing is something I can change in one place.
* Reusable components / controls, like .xibs but immediately visible
* Less flaky IBDesignable performance
Why did they choose this wierd
{ parameter in doSomething(parameter) }
syntax?
groceriesByDepartment.mapValues { items in items.count }
groceriesByDepartment.map { |item| item.count }
E.g. this reads more naturally to me:
groceriesByDepartment.mapValues { item.count in item }
otherStuff.do { a.value + b.value in a, b }
---
That said, if you consider it as "use 'items' in [a block of code]" it basically makes sense, and I could probably learn to stop worrying, and love the syntax.
for item in groceries { print item.department }
Dictionary(grouping: groceries by: { item in item.department })
In the for loop it's "for PRODUCT in SOURCE": the expression is evaluated first, and the variable is assigned with each of its items in turn. In the lambda or whatever it is, it's "{ SOURCE in PRODUCT }": first the variable is assigned, then the expression is evaluated based on it. The data flow is the opposite!
This is just objectively bad language design.
groceriesByDepartment.mapValues { $0.count } groceriesByDepartment.mapValues(&:count) # not ruby, but meh{ doSomething($0) }
doSomething
OTOH, one of things hammered into me at Microsoft was “sample code becomes production code”.
I still don’t get the benefit..
There is no support for integrated debugging, across languages on Android Studio and Visual Studio.
No support for COM or UWP and Win32 is WIP.
Not sure how much NDK APIs are actually wrapped.
Perhaps this is perception is just caused by e.g. the extremely low bar set by MinGW, which doesn't do any of that despite "supporting" Windows.
For example since Longhorn failure, COM has become the major way to introduce Windows APIs, since Vista Win32 doesn't get much love.
VSCode debugger works fine on both msvc and mingw targets.
Asking for COM or UWP is like saying that Javascript has a horrible interop story with COM/UWP. You're picking Rust to build something fast and/or low memory. Leave building a UI to the right tools.
C# has a fantastic FFI and works just fine with Rust. I actually have a project using UWP and Rust together. I get all the portability of Rust and get to use UWP as the UI frontend with minimal fuss.
Picking up your example,how do you expose and debug UWP components?
Otherwise developers are going to have lots of pain manually writting JNI wrappers to 90% of Android APIs.
Likewise on Windows with COM support.
For the time being swift on Linux is a case of a few PaaS vendors trying to product differentiate by also offering swift frameworks because they can(due to modern container wrangling) more then due to any real market demand.
Of course UIKit will still be missing, but thats sort of expected.
I'm not saying that's entirely reasonable, but it exists.
”macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux release are the current supported host development operating systems”
Also, on the page you reference:
”Note that all compiled Swift binaries are only executable within Bash on Windows and are Ubuntu, not Windows, executables.”
I believe that "supported" here means the test suites and CI are run on those platforms. More importantly, any regressions on those platforms would be considered bugs. However, there have been partial or complete ports to several other platforms, including some weird ones.
Aside from Apple platforms, I see code in-tree for Linux, CYGWIN, Windows, FreeBSD, PS4[0], Android, and Haiku[1] (a revived BeOS). And that's not some stray LLVM code, it's in the Swift compiler itself. I've read that there was/is an out-of-tree upstream port to some IBM mainframe hardware, as well.
A bit tangential to your original point, but I think it's interesting.
[0]https://github.com/apple/swift/commit/83901998c91f9242a133aa... [1]https://github.com/apple/swift/commit/aee81d272f3147c0a9b610...
This is a good start, at least for Android hardware..
To me it was nothing but progress compared to 8 apart from that. Everything faster and better.
I agree on faster and better, but still buggy. Autocomplete still regularly dies for me and requires a restart (of Xcode.)
It’s worse than no completion, you never know when it’s actually going to work.
I guess it does do something though, for eating up all those cycles.
This.
Whenever my fans start spinning up, I head on over to Activity Monitor and sure enough SourceKitService is sitting at 120% CPU draining battery like nothing else.
I probably kill the service between 5-10 times a day when using Xcode.
I've found that disabling 'live issues' in preferences helps somewhat, at the expense of not getting live updates to errors as I'm typing, but SourceKitService will still go off the deepend - usually while adding stuff that will not yet compile because I haven't included the appropriate headers yet or am still refactoring/moving about code.