Shouldn’t Foundation give off warnings when NSUnimplemented is bound to appear?

Evolution Discussion
1

Many proyects that appear to be cross-platform crash on Linux because they use some function that returns NSUnimplemented outside of Darwin. I’m currently fishing for these kinds of bugs in two libraries that I’m porting to Linux and so far they are kind of a pain to find.

Could the compiler show some kind of warning when compiling against these components in a platform where they aren’t implemented?

I was thinking of @harlanhaskins’s #warning and #error primitives, but I think those would only appear if Foundation were to be compiled alongside the project. If you’re using binaries of the library, those would’ve been read and deleted already before you needed the warnings to help you.

What can be done about this? Currently I’m just grep-ing the heck out of my files looking for culprits :sweat_smile:

3 Likes
2

I think they should be able to use @available(*, unavailable, message: "Not implemented") so you can't call unimplemented functions.

Maybe you could annotate ones you find and submit a pull request?

2 Likes
3

Ohh, that sounds good! I’ll look into it :slight_smile:

Foundation could use these tools in the meantime, while it’s not fully baked yet.

4

I thought of the same solution until I saw @Tony_Parker's explanation of why it is probably not the best approach.

5

My position on this has evolved over time, with continued improvements to the maturity of the library.

If we have entire chunks of functionality that are entirely NSUnimplemented, we should likely consider either removing it or annotating it. If we have a corner case of one method that is not available, we have to decide if we want to disallow all usage of it, or allow it but make the corner case assert. There are valid arguments in both directions.

2 Likes
6

Can you let us know what functionality these libraries needed that is missing?

It may seem strange, but we actually have very little visibility into what projects need what functionality. If we can gather some data I can prioritize which work will have the most impact.

7

Sure! Just gimme a couple of weeks... I’m still fishing (and I do this on my free time, so it might take more than two weeks).

8

Thanks. I appreciate the help.

I do want to emphasize that we really care a lot about making swift-corelibs-foundation a complete library.

3 Likes
9

That is really good to hear :relieved::slightly_smiling_face:

10

@Tony_Parker, I remembered a problem we had with x-platform APIs: FSEvents.

It isn't part of Foundation, but we had problems wanting to use that functionality while working to port SourceKittenDaemon to Linux. In the end, I forked a project that wrapped a similar API on Linux and used it with an #if os(...) compiler directive. Atm, @Ponyboy47 is working on a new, more complete wrapper :heart:

I know it isn't Foundation-related, but it's a similar kind of issue. I know you probably have other priorities to work on, but I bet you'd probably still like to hear about this :)

11

Allright. I didn’t find it, but RLovelett did:

Fatal error: waitForDataInBackgroundAndNotify() is not yet implemented: file Foundation/FileHandle.swift, line 348

We’re working on porting langserver-swift to Linux, and as you can see in the port’s branch, that’s one of the items to address in our todo-list.

12

The Swift Package Manager suffers as well from that file missing functionality. Here’s what is used to discover tests in a package, and here’s the function that uses it.

@Tony_Parker there you go :3 this message and the one before it are examples of missing Foundation functionality that would help a very great deal :blush:

13

Thanks @felix91gr!

1 Like