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.
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. Félix > Le 5 août 2016 à 11:00:58, Taras Zakharko <[email protected]> a écrit : > > You could use the pointer/raw memory API to implement that. > > 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. > > 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. > > Best, > > Taras > >> 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>{ ... >> }`? >> >> Seems to me that the first step would be actual language support for >> non-parametrizable fixed-size arrays. >> >> Félix >>> Le 5 août 2016 à 04:53:20, Taras Zakharko via >>> swift-evolution<[email protected](mailto:[email protected])>a >>> écrit : >>> >>> >>>> A few things immediately spring to mind: >>>> • Fixed-size arrays >>>> • An optimized Matrix type >>>> • Swifty syntax for Fourier transforms >>>> • A numerical integrator (or diff-eq solver!) >>>> • BigInt capabilities >>>> >>>> The first of these (fixed-size arrays) will probably require compiler >>>> support. >>> >>> Fixed-size arrays should be easy enough to implement if the Swift generics >>> are enhanced with support for constraints beyond type variables. E.g. >>> >>> struct Vector<T, count: Int>{ … } >>> >>> var x : Vector<Float, count=16> >>> >>> or even >>> >>> struct SparseTensor<T, dimensions : [Int]>{ … } >>> >>> var x: SparseTensor<Float, dimensions = [100, 100, 100, 100]>= >>> SparseTensor(withValue: 0) >>> >>> 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. >>> >>> Best, >>> >>> Taras >>> >>>> >>>> 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?) >>>> >>>> Nevin >>>> >>>> >>>> >>>> On Wed, Aug 3, 2016 at 8:41 AM, Björn >>>> Forster<[email protected](mailto:[email protected])(mailto:[email protected])>wrote: >>>>> Hello Swift community, >>>>> 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. >>>>> >>>>> 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. >>>>> >>>>> Which functionality should be covered by a Swift's math lib and where >>>>> should be drawn the line? >>>>> >>>>> Any thoughts? >>>>> >>>>> (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) >>>>> >>>>> Björn >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected](mailto:[email protected])(mailto:[email protected]) >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected](mailto:[email protected]) >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
