Issues building on Linux with swift 3.0.1

[Ponyboy47]

Issues building on Linux with swift 3.0.1

[Ponyboy47]

This compiles correctly, with only minor warnings on macOS

What branch did you try on macOS and was it converted to Swift 3 syntax in Xcode? Thanks.

[nvzqz]

What's the status on this? @Ponyboy47

[Ponyboy47]

@TRIPS-APP I was using the master branch on macOS. I just cloned the repo and tried building it.

@nvzqz It's been a long time since I even looked at this repo. I started using kylef/PathKit, but I'm going to look into this one and give it another shot and see if I can't get it compiling on Linux.

[nvzqz]

@Ponyboy47 part of my plan for this month is to make some improvements to FileKit + improve compatibility issues + add Swift 4 support. So I'll try to tackle this as soon as I can.

[Ponyboy47]

Well I just noticed some weird swift behavior on linux and ended up filing a bug (https://bugs.swift.org/browse/SR-5382).

For whatever reason, the file TextFile.swift cannot be named that or else it thinks String does not conform to ReadableWritable. Renaming TextFile.swift to StringFile.swift solves those build issues, but I have no idea why. Just thought I'd mention the bug ticket I filed for swift and gave the heads up about renaming that file (at least until the swift devs identify/fix the problem).

[nvzqz]

That's an oddly specific bug. 😅

[Ponyboy47]

So I've gotten most everything fixed for linux on my local fork except for 4 errors.

1. For whatever reason, on linux, the FileManager delegate property is read-only. So the _FMWrapper doesn't work.
   @nvzqz Is there a specific reason for the _FMWrapper in Path.swift instead of just using the default file manager? I can probably work around that if it is necessary, but it would be easier if I didn't.
2. NSData cannot be constructed using a non-required initializer NSData.init(contentsOfFile: String).
3. NSArray cannot be constructed using a non-required initializer NSArray.init(contentsOfFile: String).
4. NSDicitonary.init(contentsOfFile: String) has become deprecated. This functionality will probably be broken until the update to Swift 4 using the new JSON encoder. As such, I may start working on the update to swift 4 myself. I really would like to see this working on Linux

I'm tempted to remove everything related to NSData/NSArray/NSDictionary for linux anyways since linux users generally try to stick with the newer swift types Data, Array, & Dictionary. There's still a lot of missing functionality from Foundation on Linux and the linux swift community finds that it's easier to avoid Foundation wherever possible.

[nvzqz]

I don't remember exactly why I made _FMWrapper. I believe it was because I wanted to allow assigning a delegate to a specific path. This feels like a waste looking back at it. It should definitely be removed in a 5.0 version.

Regarding the NS-APIs, some of it should also go. I'm thinking I may reinvent the wheel a bit and remove the need for FileManager and use the C API directly if this doesn't rely on any FileManager-specific functionality.

Admittedly, there's many of aspects that I want to change but just haven't felt like changing or had the time to. I've been playing around with Rust quite a bit and I love how file management is implemented in their standard library.

[Ponyboy47]

I would love to remove most of the reliance on Foundation. That would be the best way to ensure this is cross-platform. Obviously we will need a little bit of Foundation for things like the Data type and probably a couple other things. I don't have a problem with using FileManager because it does let us avoid reinventing the wheel, but if that's what you want to do then I'd be more than happy to get my hands dirty.

I can't wait for the day when the objective c layer has been completely rewritten in swift and everything in the swift standard library has been implemented for all platforms...I dream of that day. The Swift Server Side community is pushing pretty hard to get a lot of standard library completed for linux.

[Ponyboy47]

Well I'm going to go crazy on my branch and do some pretty substantial refactoring to get this working on linux and to remove a bunch of stuff that just won't work in linux

I'll even throw in my own swift 4 updates...wish me luck

[nvzqz]

Getting #48 sorted out while FileKit is 4.x would be great.

Regarding cross platform compatibility, it's interesting how some things aren't just on an implementation level but also a compiler level. Here's a perfect example nvzqz/RandomKit@0c06830

[Ponyboy47]

I'll probably wait for linux support until 5.0 since it will probably take a pretty substantial effort to remove _FMWrapper and several of the NSTypes. I'll focus on #48 and getting FileKit Swift 4 ready for now