Introduce UnsupportedPlatformError

[armanbilge]

This will be helpful for the else case of conditional linking statements we will use for #2.

[LeeTibbert]

Code as-is LGTM.

For a discussion over beverages, not to hold up present progress.

Since we have LinktimeInfo and alternate compilation paths, I probably
would have introduced a compile time error with a good comment, on
the "Unsupported" path. That would inform the developer earlier in the cycle.

Right now, the "throw" code looks like a runtime error and quacks like
a link error.

Scala does not have C's "#error". Sometime when I am not at my work machine
and am spending time on the cell phone, I can rat around and see what the
current Scala 2 & 3 conventions are.

[LeeTibbert]

FYI & for future reference , not to hold up current rapid & welcome progress.

Scala 3: https://docs.scala-lang.org/scala3/guides/macros/compiletime.html

inline def doSomething(inline mode: Boolean): Unit =
  if mode then ...
  else if !mode then ...
  else error("Mode must be a known value")

doSomething(true)
doSomething(false)
val bool: Boolean = ...
doSomething(bool) // error: Mode must be a known value

If error is called outside an inline method, the error will be emitted when compiling that call. If the error is written inside an inline method, the error will be emitted only if, after inlining the call, it is not removed as part of a dead branch. In the previous example, if the value of mode were known at compile time, we would only keep one of the first two branches.

Doubtful that there is something similar in scala 2. Perhaps a good comment and the compilation error of error() not
being defined would be enough.

[armanbilge]

Thanks for your ideas. Actually I would like to be thoughtful about this proposal.

I probably would have introduced a compile time error with a good comment, on
the "Unsupported" path.

I am not entirely sure how this would work. I am almost certain we want a link-time error: the problem is, we are publishing pre-compiled artifacts. So when a developer wants to build an application with the epollcat dependency, they will not be compiling our code, only linking it. So our only opportunity to stop them will be at link time.

I do agree it would be nice if we could directly inject a link-time error (similar to how in Scala 3 we can inject a compile-time error) instead this "hack". But I do not think that's possible.

[LeeTibbert]

 am not entirely sure how this would work. I am almost certain we want a link-time error: the problem is, we are publishing pre-compiled artifacts. So when a developer wants to build an application with the epollcat dependency, they will not be compiling our code, only linking it. So our only opportunity to stop them will be at link time.

Ah, now I understand. Concern resolved, thank you for your patience.

I have been building too many things from scratch and it has frozen my
perspective.

How does the larger ecosystem deal with less-than-universal artifacts. Say for
apple Intel but not M1. Naming of the artifact?

[armanbilge]

How does the larger ecosystem deal with less-than-universal artifacts. Say for
apple Intel but not M1. Naming of the artifact?

Yes, I think for less-than-universal artifacts they are published separate under different names.

We are operating in bit of a strange space: we are distributing compiled artifacts, but they have been compiled to NIR and not yet to platform-specific code. Thus platform-specific differences are resolved at linking time. This is unlike C for example, where platform issues are resolved at compile-time via preprocessor macros.