Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dictionary and Set Improvements in Swift 4.0

swift.org

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Dictionary and Set Improvements in Swift 4.0

#61

Post by jakobegger »

smitherfield wrote: post #55
Groxx wrote: post #43

Earlier quoted context omitted.

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

I prefer Ruby's syntax too, but Swift also has a shorthand version which is, IMO, usually nicer. groceriesByDepartment.mapValues { $0.count }

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

Re: Dictionary and Set Improvements in Swift 4.0

#62

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

Re: Dictionary and Set Improvements in Swift 4.0

#63

Post by mantas »

jakobegger wrote: post #61
smitherfield wrote: post #55

Earlier quoted context omitted.

I prefer Ruby's syntax too, but Swift also has a shorthand version which is, IMO, usually nicer. groceriesByDepartment.mapValues { $0.count }

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

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

Re: Dictionary and Set Improvements in Swift 4.0

#64

Post by edejong »

azinman2 wrote: post #60

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.

Why stop at identifiers when you can have C++ #defines? http://lallouslab.net/tag/emoji/

Re: Dictionary and Set Improvements in Swift 4.0

#65

Post by dep_b »

jarjoura wrote: post #53
dep_b wrote: post #5

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…

Storyboards kind of suck for any team bigger than 1 as far as I’m concerned. They also lock you into a visual binding style development pattern the doesn’t scale as your app grows. Don’t get me wrong, they’re great for fast prototyping or teaching someone how to write code as it helps with a ton of boilerplate.

I think that's a bit overstated but it really depends what kind of application you're writing. I have an accounting app I maintain alone where I almost completely abandoned storyboards because a lot of screens had similar elements and it was very important to have all data reliably passed around. Also helped with consistency and maintainability. On the other hand I'm doing a new app with three people now where we use storyboards because every screen is vastly different.

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

Re: Dictionary and Set Improvements in Swift 4.0

#66

Post by marvel_boy »

augbot wrote: post #50
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..

Amazing. Thanks for the link.

Re: Dictionary and Set Improvements in Swift 4.0

#67

Post by pjmlp »

vvanders wrote: post #51
pjmlp wrote: post #41

Earlier quoted context omitted.

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.

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

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?

Re: Dictionary and Set Improvements in Swift 4.0

#68

Post by pjmlp »

Rusky wrote: post #45
pjmlp wrote: post #41

Earlier quoted context omitted.

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.

Those stacks are more than just UI.

For example since Longhorn failure, COM has become the major way to introduce Windows APIs, since Vista Win32 doesn't get much love.

Re: Dictionary and Set Improvements in Swift 4.0

#69

Post by mikestew »

azinman2 wrote: post #60

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.

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

Re: Dictionary and Set Improvements in Swift 4.0

#70

Post by favorited »

lozenge wrote: post #57
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…

I see Swift supports generics so could they let you define subclasses of string enums that support custom string values?

Swift also supports associated values with enum cases, so you could do something like this[0] and get type-safety. Now you could only associate a URL type with a link attribute, or an NSColor type with a foregroundColor attribute, etc.

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

Post reply on HN