> On Dec 21, 2015, at 8:16 AM, Jens Persson via swift-evolution 
> <[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to