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

51–60 of 71 posts

Re: Dictionary and Set Improvements in Swift 4.0

#51

Post by vvanders »

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.

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.

Re: Dictionary and Set Improvements in Swift 4.0

#52

Post by slavapestov »

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?

Functions are values in Swift. Closure literal syntax is just a shorthand where you don’t have to name the function first.

Re: Dictionary and Set Improvements in Swift 4.0

#53

Post by jarjoura »

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.

Re: Dictionary and Set Improvements in Swift 4.0

#54

Post by Camillo »

Groxx wrote: post #43
thedjinn wrote: post #29

Earlier quoted context omitted.

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

I agree, the examples in the article look terribly confusing. And they're inconsistent with Swift's own for loop syntax: https://developer.apple.com/library/content/documentation/Sw...

    for item in groceries { print item.department }
versus:

    Dictionary(grouping: groceries by: { item in item.department })
The people who chose this syntax probably said "hey, it's VARIABLE in EXPRESSION, same thing right?". But the semantics are completely different!

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.

Re: Dictionary and Set Improvements in Swift 4.0

#55

Post by smitherfield »

Groxx wrote: post #43
thedjinn wrote: post #29

Earlier quoted context omitted.

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

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

  groceriesByDepartment.mapValues { $0.count }

Re: Dictionary and Set Improvements in Swift 4.0

#56

Post by nielsbot »

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?

I think Swift's philosophy is to use keywords when possible instead of symbols, for better typability.

Re: Dictionary and Set Improvements in Swift 4.0

#57

Post by lozenge »

favorited wrote: post #25
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…

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?

Re: Dictionary and Set Improvements in Swift 4.0

#58

Post by imron »

indemnity wrote: post #35
nodamage wrote: post #21

Earlier quoted context omitted.

Xcode 9 has been a lot less stable for me compared to previous versions. It will lock-up multiple times per day during simple text editing tasks, with SourceKitService going bananas until I force quit it.

It boggles the mind that they just can’t seem to fix SourceKitService for three versions now, it’s such a massive part of making the Xcode experience suck. 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.

> it’s such a massive part of making the Xcode experience suck.

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.

Re: Dictionary and Set Improvements in Swift 4.0

#59

Post by sizeofchar »

BillinghamJ wrote: post #37
thedjinn wrote: post #29

Earlier quoted context omitted.

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

Well, for starters, what does it mean? I haven’t seen that in any other language.

Haskell have let-in expressions, I think it is the inspiration for swift in this case.
Post reply on HN