Dictionary and Set Improvements in Swift 4.0 • Hacker News Board

Re: Dictionary and Set Improvements in Swift 4.0

#41

Post by pjmlp » Wed, Oct 04, 2017, 11:40 PM UTC

vvanders wrote: post #17

Stanleyc23 wrote: post #8

Earlier quoted context omitted.

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

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

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.

Re: Dictionary and Set Improvements in Swift 4.0

#42

Post by jayrhynas » Thu, Oct 05, 2017, 12:21 AM UTC

reednj wrote: post #38

slavapestov wrote: post #33

Earlier quoted context omitted.

Or just doSomething

I wasn't aware of that syntax? It will just pass the arguments from the parent to the child in order?

As long as the signature of the function matches you can pass it in directly

Re: Dictionary and Set Improvements in Swift 4.0

#43

Post by Groxx » Thu, Oct 05, 2017, 12:23 AM UTC

thedjinn wrote: post #29

potlee wrote: post #28

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?

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

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.

Re: Dictionary and Set Improvements in Swift 4.0

#44

Post by favorited » Thu, Oct 05, 2017, 12:36 AM UTC

dep_b wrote: post #36

favorited wrote: post #25

Earlier quoted context omitted.

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 unde…

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.

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.

Re: Dictionary and Set Improvements in Swift 4.0

#45

Post by Rusky » Thu, Oct 05, 2017, 12:47 AM UTC

pjmlp wrote: post #41

vvanders wrote: post #17

Earlier quoted context omitted.

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

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.

Those are probably what the parent means by "UI framework." The Rust toolchain does integrate seamlessly with those platforms' native toolchains, using the same binary and debug info formats.

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.

Re: Dictionary and Set Improvements in Swift 4.0

#46

Post by favorited » Thu, Oct 05, 2017, 1:35 AM UTC

amorde wrote: post #31

Stranger43 wrote: post #15

Earlier quoted context omitted.

It's probably going to end up similar to the equally hyped objectiveC where the core language was made portable but few of the tooling/API's used for real world OSX applications ended up supporting anything but OSX in any production ready capacity despite GNUSTEP actually shipping a ObjetiveC/OpenSTEP clone for Linux. For the time being swift on Linux is a case of a few PaaS vendors trying to product differentiate by…

One of the biggest causes of this for Objective-C was the lack of the Foundation framework (a higher-level interface to Core Foundation) - but this is being reimplemented in Swift. See https://github.com/apple/swift-corelibs-foundation Of course UIKit will still be missing, but thats sort of expected.

Not if Microsoft keeps this up: https://github.com/Microsoft/WinObjC/tree/develop/Frameworks...

I'm not saying that's entirely reasonable, but it exists.

Re: Dictionary and Set Improvements in Swift 4.0

#47

Post by dep_b » Thu, Oct 05, 2017, 1:42 AM UTC

nteunh34nteu wrote: post #27

dep_b wrote: post #10

Earlier quoted context omitted.

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.

The new key command for it is right there in the menu when it pops up. If you select the first item to do what the old command did, it's literally just to the right of the command!

Yeah....but muscle memory....

Re: Dictionary and Set Improvements in Swift 4.0

#48

Post by favorited » Thu, Oct 05, 2017, 1:49 AM UTC

Someone wrote: post #34

nerdface wrote: post #22

Earlier quoted context omitted.

You can use Swift on Windows: https://github.com/apple/swift/blob/master/docs/Windows.md

https://github.com/apple/swift/blob/master/README.md : ”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.”

> macOS, Ubuntu Linux LTS, and the latest Ubuntu Linux are the current supported host development operating systems

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

Re: Dictionary and Set Improvements in Swift 4.0

#49

Post by dep_b » Thu, Oct 05, 2017, 2:17 AM UTC

favorited wrote: post #44

dep_b wrote: post #36

Earlier quoted context omitted.

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.

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.

Yup that was exactly the one!

Re: Dictionary and Set Improvements in Swift 4.0

#50

Post by augbot » Thu, Oct 05, 2017, 2:29 AM UTC

hellofunk wrote: post #4

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

https://github.com/apple/swift/blob/master/docs/Android.md

This is a good start, at least for Android hardware..