Hacker News Reader

Comment by jakobegger | Hacker News Reader

The only thing I want from Swift 5 is easier string handling. I just want an easy and concise way to do things like split a filename into parts, extract regex matches, etc. At the moment it's faster to write string handling code in Objective C...

View on HN

> split a filename into parts

This is not something strings should do; you should be using URL instead. Foundation realized this long ago and has started deprecating string-based path APIs because treating a path as a string exposes fundamental misconceptions very quickly.

> extract regex matches

This is something that is being worked on/discussed, but has not been “solved” yet.

Are you saying just exploding a URL into its components?

I don’t understand your question. If it is “can I explode a URL into components”, the answer is that URL can do this.

I’m not sure about the specifics with swift, but I thinking he’s referring to a type, URL. Ruby has a URI module that you would use to work with uri strings, and I think that’s exactly what he is taking about.

> This is not something strings should do;

I didn't mean that String should have a "pathExtension" property like NSString. I just want operations like "insert a number before the last period" to be easier to do.

Also, there are a lot more things that are a pain with String. I mean, just the fact that I can't pass a Substring to a function that expects a String boggles my mind.

Yes, like I said, you should be using URL for this, which will make it possible to extract the filename without the extension, modify it, and get the path string from that (which is semantically what I believe you are trying to do). Not only does this create self-documenting code, it also makes it harder to fall into a the many “gotchas” that handling paths entails.

Yes, I know that, but I was just using filename manipulation as an example, because it was the first thing that came to my mind. I now see it was a bad example, since URL has a couple of APIs for file name handling.

Anyway, these types of operations come up all the time when working with strings, and these operations are really really incovenient in Swift.

> Anyway, these types of operations come up all the time when working with strings, and these operations are really really incovenient in Swift.

Again, what are these operations? I think most of the issues people have with String is due to hard to discover APIs rather than design issues with String.

Text parsing is something that comes up often (for me). For example parsing CSV files, or parsing tab separated data from the clipboard, or parsing various types of config files.

Swift has sweet solutions for a few special cases (eg. parse file names, parse dates, parse JSON), but parsing generic text is not something that Swift is good at.

NSString has a rich set of APIs for those tasks (NSScanner, NSRegularExpression, and all the rangeOfString... methods). Swift has pretty much nothing. (There is firstIndex(of:), but as far as I can see there is no way to find the next index, which makes it pretty much useless for most parsing tasks)

Maybe the problem is that I'm just not familiar enough with Swifts String, but until now every time I've had to work with Strings I became very frustrated.

I would strongly suggest that you don’t write a parser for .csv yourself, it’s a terrible format.

> I just want operations like "insert a number before the last period" to be easier to do.

Stuff.tar1.gz would like to have a word with you.

Why would URL be needed to handle file system only paths? They’re different and OS Specific. Rusts Path vs String vs third-party URL strikes the right balance IMO. It’s a third thing.

Foundation’s URL handles file system paths, among other things. Thus, it is the right choice to do path-based operations.

Sorta, it's the right choice on iOS and macOS but conceptually filesystem paths are different than URIs even though the same information can be encoded into both. It's weird to have URIs pointing at google (technically valid by means of being the same type) being passed to file-management APIs - only to have them unsurprisingly fail. It subverts the type system by allowing invalid blobs to avoid being caught by the type system. Paths as URIs in contexts where only FS paths are valid is akin to any other stringly-typed API. A third type is more logical: URL, String and FsPath.

I was playing along with Advent of Code and decided to do some of the puzzles, mainly ones where having a graphical view of what's going on would be really nice, in Swift. For reference, the other ones were done in D.

My input parsing code was inevitably a mess of stuff like:

    let parts = l.components(separatedBy: ",")
    let first = parts[0].components(separatedBy: "=")
    let second = parts[1].trimmingCharacters(in: .whitespaces).components(separatedBy: "=")

When I did puzzles in D my input parsing was just creating a regex, matching on it, and pulling out the results.

I started to look at how to do regex in Swift and it seemed easier (!) to just use .components(separatedBy:) as required. Google came up with a number of people who have created libraries/extensions that make this easier, but Swift really needs some better regex handling built in.

There's also split()

    let parts = l.split(separator: ",").map{ $0.split(separator: "=") },
        first = parts[0],
        second = parts[1]

While I agree that String parsing in Swift is quite annoying, when I started using Scanner my Advent of Code parsing experience improved

https://developer.apple.com/documentation/foundation/scanner

Also async!

Reply on news.ycombinator.com