[swift-evolution] [Pitch] #error

[Gor Gyolchanyan]

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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > On Jun 10, 2017, at 2:00 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> 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
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> -- 
> Javier Soto
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170611/965f86bc/attachment.html>