Swift 4.1

[yonaskolb]

This updates the codebase to Swift 4.1 and drops Swift 3 support

Warnings were not cleaned up in Lexer.swift as #226 will take care of that

[AliSoftware]

Only reviewed this on GitHub and not in Xcode, but what I read looks mainly ok to me.

Shouldn't we add a s.swift_version attribute in the podspec though?

[AliSoftware]

OCD-me speaking: seems like there's inconsistent indentation here compared to the rest of the file (tab vs space probably?)

[yonaskolb]

Fixed 👍

[yonaskolb]

Comments addressed and changelog entry added

[kylef]

Now requires Swift 4.1 or newer*

[yonaskolb]

Done

[djbe]

Would you mind adding the Swift 4 Lexer.swift changes to this PR?

It seems we're going to need to do some more testing, to compare #225 and #226, maybe even add some sort of test to keep track of the performance (so it doesn't tank again), and it's easier if that PR doesn't also have changes related to the Swift migration.

[yonaskolb]

I'd rather leave Lexer.swift alone. To fix the warnings means redoing the substring accessing anyway. I'd rather not cause conflicts in the other performance PRs.

[djbe]

If we're adding this property (and we have to), we should also add cocoapods_version. I think the swift_version property is available since CocoaPods 1.4.0.

[djbe]

Causing conflicts shouldn't be an issue TBH, the PRs will need a rebase anyway. I just thought that a minimal changeset for the old and new performance PRs might help us test why there's a difference.

[yonaskolb]

I just timed this with my tests. It looks like the last commit took it from 0.48 to 1.07...

[djbe]

Could it be the String( initializers? We may want to try to keep using SubStrings, as it avoids re-allocation/copy operations.

[yonaskolb]

I tried to keep things as substrings, but things like hasPrefix weren't available on linux

[djbe]

And if we define our own functions specifically for Linux?

Note: We should move this discussion to #226.