[swift-evolution] Compile time assertion / checking?

Jens Persson jens at bitcycle.com
Tue Dec 22 01:18:02 CST 2015


Thanks!
(As a side note related to overflow, I filed
https://bugs.swift.org/browse/SR-297 demonstrating that a
T : UnsignedIntegerType can be set to eg literal -1 without trapping the
overflow.)

On Mon, Dec 21, 2015 at 7:22 PM, Joe Groff <jgroff at apple.com> 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
>
>


-- 
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens at bitcycle.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151222/20daf228/attachment.html>


More information about the swift-evolution mailing list