I was playing around with Swift's mysterious Builtin module, accessible via the
`-parse-stdlib` compiler flag and I noticed a builtin primitive that causes a
fatal error if the branch it's in is not optimized away. This seems like an
opportunity for a much more powerful "this place is not implemented", where the
execution branch analyzer can determine at compile time for specific cases
whether or not the unimplemented branch will be accessed. We could make a
proposal to introduce a new compiler directive of the following form:
public func #unavailable(_ message: String? = nil) -> Never
This directive would be allowed both in function scope and global scope.
Calls to this directive would generate a compile-time error when the execution
path it's located in can be guaranteed and a run-time error in all other cases.
Placing this directive in the global scope would generate a compile-time error
unconditionally.
The only way to avoid this error is to either have the call to it optimized
away or conditionally compiled out:
#if os(macOS)
import Cocoa
#else
#unavailalbe("Sorry, pal. I only work with macs.")
#endif
func compare(_ x: Int, _ y: Int) -> Int {
if x > 0 {
return 1
} else if x == 0 {
return 0
} else if x < 0 {
return -1
} else {
#unavailable("How the hell did you managed to get here?")
}
}
> On Jun 11, 2017, at 7:45 PM, Javier Soto via swift-evolution
> <[email protected]> wrote:
>
> +1 on adding a compile-time error directive. #error seems like the right
> syntax as well.
> I had a maybe nit-picky comment about the proposal though. I think the
> example may not be ideal, since you could accomplish that compile-time error
> by annotating the method or class where that code lives with @available(tvOS)
> , no?
> On Sun, Jun 11, 2017 at 9:18 AM Will Field-Thompson via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> This is the best I've found for searching the archives:
> https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22
>
> <https://www.google.com/search?q=site%3Ahttps%3A%2F%2Flists.swift.org%2Fpipermail%2Fswift-evolution%2F+%22%23error%22>
>
>
>
> On Sun, Jun 11, 2017 at 11:30 AM Daryle Walker via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
> > On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Daryle, there have been several pitches in the past with respect to #error,
> > and very enlightening arguments both for and against the idea have been
> > eloquently written.
> >
> > Since you’re resurrecting this idea, could I suggest going back through the
> > archives and linking to and summarizing these arguments, so that we’re not
> > restarting the discussion from scratch? :)
>
> Is there somewhere to search the archives?
>
> —
> Daryle Walker
> Mac, Internet, and Video Game Junkie
> darylew AT mac DOT com
>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> --
> Javier Soto
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
