[swift-evolution] Compile time assertion / checking?

marc hoffman mh at remobjects.com
Tue Dec 22 09:26:44 CST 2015


Joe,

quick side question: is @_transparent documented somewhere? I’ve seen it in the standard library source code, but i cannot see out covered in any of the docs…

thanx!
marc

> On Dec 21, 2015, at 2:22 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Dec 21, 2015, at 8:16 AM, Jens Persson via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Sorry if this has been asked before (searched but couldn't find anything).
>> I'll explain what I mean by an example of a situation where I think it would be reasonable to expect a compile time error rather than the current runtime error:
>> 
>> import simd
>> let a: float4 = [1, 2, 3]
>> print(a)
>> 
>> The SIMD float4 type conforms to ArrayLiteralConvertible, and the required initializer has a check that makes sure the array literal has 4 elements.
>> The check can only be performed at runtime even though the number of elements of that array literal is (presumably) statically knowable, as is the number it is checked against (i.e. it probably ends up being an integer literal 4 somewhere (although I haven't actually checked the code)).
>> 
>> I assume that there are good reasons for why this is currently a runtime check, but I'd like to know what these reasons are, i.e. why isn't there something like C++'s static_assert?
>> 
>> Any pointers to previous discussions or information about how Swift relates to this and similar topics (static computation / constexpr, macro system) would be highly appreciated.
> 
> We haven't designed any facilities for any of this yet, or really had serious discussions about them that I know of. They're definitely interesting directions for the future. There is some infrastructure for limited compile-time evaluation and diagnostics based on SIL; for instance, we produce diagnostics when literal integer expressions overflow their target type, as in `let x: Int8 = 128`, by doing constant-folding of `@_transparent` functions. There's a more generalized compile-time reporting mechanism we prototyped, but I don't think we currently take advantage of it; grep around for `staticReport`. `staticReport` in @_transparent function together could approximate static_assert in cases the compiler knows how to constant-fold.
> 
> -Joe
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list