# How can i return from a function an array or slice with different dimension like \[\]\[\]T or \[\]\[\]\[\]T **URL:** \ **Category:** Help\ **Tags:** language, multi-dimensional\ **Created:** [October 3, 2024, 7:19am UTC](https://ziggit.dev/t/how-can-i-return-from-a-function-an-array-or-slice-with-different-dimension-like-t-or-t/6234 "2024-10-03T07:19:36Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![Sze](https://ziggit.dev/user_avatar/ziggit.dev/sze/32/496_2.png) [@Sze](https://ziggit.dev/u/Sze)\ **Post date:** [October 3, 2024, 3:57pm UTC](https://ziggit.dev/t/how-can-i-return-from-a-function-an-array-or-slice-with-different-dimension-like-t-or-t/6234/4 "2024-10-03T15:57:38Z")
comptime vs runtime That is the main issue I see here, you need to decide between either handling the shape at comptime which would allow you to use different types depending on the shape picked at comptime, or handle it all at run time which means you need to pick a type that can handle all shapes. I think one way you could do this is by renaming/repurposing `toArray` to `toShape` and adding a comptime `shape` parameter to it, which then is used to calculate the return type, within the body of the function you check at run time that the runtime shape matches the comptime shape, if it doesn’t you either error or panic. Another problem is the whole issue of multidimensional slices (slices need their own storage and point to other storage combined with creating new data, you end up needing dynamic memory allocation), if you are going this route where the shape has to be provided as a comptime parameter, then there isn’t a good reason to use slices at all, because if the shape is known at comptime you can instead use multidimmensional arrays like in this answer: > [@Creating a big 2D array](https://ziggit.dev/t/creating-a-big-2d-array/6178/8): > > I think the best solution would be to allocate the entire 2d array in one piece on the heap, instead of allocating them in parts. This is much simpler and should give you a better memory layout: const A: \*[n][n]u64 = try allocator.create([n][n]u64); defer allocator.destroy(A); If you don’t want to provide the shape as a comptime parameter, you could instead return a tagged union that enumerates the possible variants (effectively just delaying the choice by wrapping it in a type that can represent every choice), but if you want to support a wide combination of possible shapes that might end up too messy and difficult. Also in the end the union would mostly serve as a way to indicate at run time which of the shapes was chosen and then the person receiving the value would have to switch on the tagged union, selecting one of its variants (and at that point that code branch would again know the shape at comptime (because that branch only gets chosen for that variant)). Overall I think it would be helpful if you described your overall goals and constraints, so that we can make more specific suggestions how you could reach your goal. For example whether you really want to process all kinds of generic shapes, or more specific ones, whether you know which shapes will ever be needed at comptime, or your program only finds that out at run time. How you need to access the data, what operations you need on the data, etc. It is easier to deal with (and write efficient code for) specific comptime known shapes then having to deal with all possible shapes at run time. * * * You also might be interested in these projects: > [@Zein - a Zig based Tensor library](https://ziggit.dev/t/zein-a-zig-based-tensor-library/649): > > Hello! I’m excited to be apart of the Zig community and it’s quickly become my language of choice for development! The project that I’d like to introduce is Zein (Z for zig, ein for einsum/tensor stuff). I am planning on doing a full scale support of AVX (currently used for fast tensor indexing) and CUDA at some point! Please check it out at: [GitHub - andrewCodeDev/ZEIN: Zig-based implementation of tensors](https://github.com/andrewCodeDev/ZEIN) I am looking to collaborate with people, have my code reviewed and just interact with… > [@Metaphor: GPU machine learning library for Zig](https://ziggit.dev/t/metaphor-gpu-machine-learning-library-for-zig/3317): > > Hey everyone! I’ve been slowly hacking away at a Torch like library for Zig. This is an on going passion project of mine that I’m excited to be share. It’s a combination of Cuda, C, C++, and of course, Zig. Metaphor is intended to be a torch-like library for Zig. The goal is to have a simple syntax that feels pythonic without sacrificing low level control. Mixing Zig with Cuda Metaphor is entirely GPU driven and it’s focused on working with large data. After a lot of tinkering, I believe … I don’t understand the details of those projects well enough, but from what I have gathered they also deal with lots of different dimmensional data, so there may be something there that is related to what you are trying to do. --- _[View the full topic](https://ziggit.dev/t/how-can-i-return-from-a-function-an-array-or-slice-with-different-dimension-like-t-or-t/6234)._