<div dir="ltr">Thanks!<div>(As a side note related to overflow, I filed <a href="https://bugs.swift.org/browse/SR-297">https://bugs.swift.org/browse/SR-297</a> demonstrating that a</div><div>T : UnsignedIntegerType can be set to eg literal -1 without trapping the overflow.)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 7:22 PM, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Dec 21, 2015, at 8:16 AM, Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Sorry if this has been asked before (searched but couldn't find anything).<br>
> 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:<br>
><br>
> import simd<br>
> let a: float4 = [1, 2, 3]<br>
> print(a)<br>
><br>
> The SIMD float4 type conforms to ArrayLiteralConvertible, and the required initializer has a check that makes sure the array literal has 4 elements.<br>
> 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)).<br>
><br>
> 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?<br>
><br>
> 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.<br>
<br>
</span>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.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Joe<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden<br><a href="http://www.bitcycle.com/" target="_blank">http://www.bitcycle.com/</a><br>Phone: +46-73-753 24 62<br>E-mail: <a href="mailto:jens@bitcycle.com" target="_blank">jens@bitcycle.com</a><br><br></div>
</div>