<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">If you'd allocate memory for a fixed-size array, you might as well use a non-fixed-size array. You need the overhead of a full object header to be able to implement copy-on-write semantics anyway.<div class=""><br class=""></div><div class="">Right now, C fixed-size arrays are imported as tuples. int[4] translates to (Int32, Int32, Int32, Int32). If nothing else, fixed-size arrays as first-class constructs would let you access objects at a variable index or iterate over them without doing the little raw pointer dance.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 5 août 2016 à 11:00:58, Taras Zakharko <<a href="mailto:taras.zakharko@uzh.ch" class="">taras.zakharko@uzh.ch</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">You could use the pointer/raw memory API to implement that. <br class=""><br class="">One reason why I dislike the idea of introducing fixed-size arrays as a first-class language feature is that it adds an additional construct with quite niche use. Non-type generic parameters instead give you a powerful tool that you can use to implement all kinds of things. <br class=""><br class="">BTW, another way to have fixed-size arrays would be to extend the tuple type. However, if i understand correctly, the biggest optimisation potential comes from knowing the size of the array at the compile time. So we do need some sort of specialisation parameter. <br class=""><br class="">Best, <br class=""><br class=""> Taras<br class=""><br class=""><blockquote type="cite" class="">I don't think that non-type generic arguments are enough to create fixed-size arrays. How would you fill in `struct Vector<T, count: Int>{ ... }`?<br class=""><br class="">Seems to me that the first step would be actual language support for non-parametrizable fixed-size arrays.<br class=""><br class="">Félix<br class=""><blockquote type="cite" class="">Le 5 août 2016 à 04:53:20, Taras Zakharko via swift-evolution<<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>(<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>)>a écrit :<br class=""><br class=""><br class=""><blockquote type="cite" class="">A few things immediately spring to mind:<br class="">• Fixed-size arrays<br class="">• An optimized Matrix type<br class="">• Swifty syntax for Fourier transforms<br class="">• A numerical integrator (or diff-eq solver!)<br class="">• BigInt capabilities<br class=""><br class="">The first of these (fixed-size arrays) will probably require compiler support.<br class=""></blockquote><br class="">Fixed-size arrays should be easy enough to implement if the Swift generics are enhanced with support for constraints beyond type variables. E.g.<br class=""><br class="">struct Vector<T, count: Int>{ … }<br class=""><br class="">var x : Vector<Float, count=16><br class=""><br class="">or even<br class=""><br class="">struct SparseTensor<T, dimensions : [Int]>{ … }<br class=""><br class="">var x: SparseTensor<Float, dimensions = [100, 100, 100, 100]>= SparseTensor(withValue: 0)<br class=""><br class="">I believe that something like this was mentioned in the discussion of the Generics Manifesto. If you are interested in making Swift more suitable for numerical operations, I’d say that the first order of business is to work towards implementing this sort of generic constants.<br class=""><br class="">Best,<br class=""><br class="">Taras<br class=""><br class=""><blockquote type="cite" class=""><br class="">The rest can already be done in a library, except I believe they will hit the “generics cannot be specialized across module boundaries” slowdown, and must be explicitly specialized for common numeric types to avoid it. (Has this been fixed yet? Are there plans to?)<br class=""><br class="">Nevin<br class=""><br class=""><br class=""><br class="">On Wed, Aug 3, 2016 at 8:41 AM, Björn Forster<<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>(<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>)(<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>)>wrote:<br class=""><blockquote type="cite" class="">Hello Swift community,<br class="">to make use of Swift more appealing and useful for science, engineering and finance and everything else involving actually calculating things, I think it would be a big step forward if Swift would ship with its own math/numerics library.<br class=""><br class="">Wouldn't it be great if Swift would offer functionality similar to Numpy in its native math lib? It think it would be great to have a "standard" annotation for vector arithmetic that the Swift community has agreed on and that scientific packages can build on.<br class=""><br class="">Which functionality should be covered by a Swift's math lib and where should be drawn the line?<br class=""><br class="">Any thoughts?<br class=""><br class="">(If it is not the right time now to talk this topic, as it is not mentioned in the goals for Swift 4 by Chris, I apologize for bringing this up now. But I think then this should be discussed later at some point not in the infinite future)<br class=""><br class="">Björn<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>(<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>)(<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>)<br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote><br class=""><br class=""><br class=""></blockquote>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>(<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>)<br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote><br class=""><br class=""></blockquote></div></div></blockquote></div><br class=""></div></body></html>