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
