
Dictionary and Set Improvements in Swift 4.0 - Nuance
https://swift.org/blog/dictionary-and-set-improvements/
======
dep_b
The language definitely feels like it has matured as the change from 3.0 to
4.0 was pretty much painless. The big issue with programming in Swift is no
longer swift itself but the libraries around it. A lot of the API's you use in
day to day Cocoa programming are based on Objective-C and often stringly typed
and not very compile safe.

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.

~~~
favorited
Attributed Strings got better type information in Swift 4 (it got what
Notification keys got in Swift 3), but like notifications it's an open-ended
API so I don't know what else you can do...

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.

~~~
dep_b
True, but that's exactly the kind of change to the API required to make it
more compile-safe. I still managed to crash this API by not providing a
.rawValue somewhere. I don't think applications need to crash on key-value
errors.

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.

~~~
favorited
Ahh right, NSUnderlineStyle... I totally thought that was improved in Swift 4,
what a bummer. I have some unit tests in my apps that make sure I'm setting
the .rawValue instead of the enum case itself, because that one does suck. I'm
gonna file a bug.

~~~
dep_b
Yup that was exactly the one!

------
potlee
Some nice improvements but could have really used a syntax for anonymous
functions that makes.

Why did they choose this wierd

{ parameter in doSomething(parameter) }

syntax?

~~~
thedjinn
Looks fine to me. What's wrong about that syntax?

~~~
Groxx
Feels backwards to me, at least as a gut feel.

    
    
        groceriesByDepartment.mapValues { items in items.count }
    

vs e.g. Ruby (or at least close, it has been a while):

    
    
        groceriesByDepartment.map { |item| item.count }
    

The "in" makes it feel like you're calling "items.count" on...? and then
getting the "items" from it (since it sorta implies that items _are in_
items.count, which seems like nonsense).

E.g. this reads more naturally to me:

    
    
        groceriesByDepartment.mapValues { item.count in item }
        otherStuff.do { a.value + b.value in a, b }
    

which would also move the "what it does" further to the left, rather than
having to skip over the argument names (which are frequently obvious in
context, and/or something trivial like "it" or "item" or "x").

\---

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.

~~~
smitherfield
I prefer Ruby's syntax too, but Swift also has a shorthand version which is,
IMO, usually nicer.

    
    
      groceriesByDepartment.mapValues { $0.count }

~~~
jakobegger
The shorthand version doesn‘t let you specify argumen types (only works when
they can be inferred)

~~~
mantas
Which is vast majority of cases. Unless you work with a lot of legacy ObjC
code.

------
azinman2
The emojis are cute in this description of language changes, but I’m worried
some programming newbies will look at this as an example of “pros” / Apple
endorsing it and will start using them in real programs.

~~~
mikestew
One of the many reasons you have code reviews. A formal review isn’t even
necessary, since the first time anyone but the author sees the code, the
ensuing ridicule will ensure that it never happens again.

OTOH, one of things hammered into me at Microsoft was “sample code becomes
production code”.

------
pbarnes_1
Please give us concurrent collections.

------
bsaul
I was a bit disappointed at the string api in swift4 recently. They removed
the need to access characters every time, but they kept the Index type, which
adds an intermediate step every time you want to build a range, without
providing any more safety than just using integers: it still crashes on index
out of bounds, so you still need to manually bound check, only you have to
compare to startIndex and endIndex.

I still don’t get the benefit..

------
hellofunk
I really wish Swift could find a way to be useful on platforms other than
Apple. I'd be willing to commit more to it if I could write truly portable
code in it. It's got a good start on Linux, but Windows and Android would be
cool too. Though Kotlin won out over Swift for Android (very similar languages
but I like Swift a bit better there).

~~~
Stanleyc23
let's say android or windows adopted swift. I don't think that would eliminate
the biggest learning curve of dealing with the frameworks. in my experience,
learning UIKit stuff was way trickier than swift. I imagine the same
experience developing for other OS'.

~~~
vvanders
I dunno how true that is, Rust has fantastic support across Windows and
Android but leaves UI framework up to the platform.

~~~
pjmlp
I wish Rust had such fantastic support you claim.

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.

~~~
vvanders
I hate to be a bit blunt but you're really barking up the wrong tree.

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.

~~~
pjmlp
I am just raising awareness, it is all a matter if you feel like it matters to
earn the hearts of. Windows developers using to their VS, C# + C++ and
respective tooling productivity.

Picking up your example,how do you expose and debug UWP components?

------
dandr01d
I really wish Apple would focus more on getting Xcode up to par. It's in a
truly horrid state, both performance and feature-wise. Developing an
Objective-C app is worlds ahead of Swift right now.

~~~
hellofunk
Are you aware that Xcode 9 just shipped last week and is a major rewrite of
much of the IDE? It's one of the largest updates in Xcode's history.

~~~
sho_hn
So ... any good?

~~~
dep_b
The only that truly annoyed me was that CMD+click doesn't work immediately
anymore but conjures some kind of intermediary menu. Haven't figured out if
there's a new keystroke for it, but I'm still doing too much work in Xcode 8.

To me it was nothing but progress compared to 8 apart from that. Everything
faster and better.

~~~
jclardy
There is a checkbox in Xcode preferences to change it back. Not sure where as
I’m on mobile, but that annoyed me to no end till I found the option.

I agree on faster and better, but still buggy. Autocomplete still regularly
dies for me and requires a restart (of Xcode.)

~~~
rockshassa
Preferences > Navigation > "Command Click on Code"

