mohu-array/src/array.rs is empty — core NdArray<T> type not implemented

[Bbn08]

crates/mohu-array/src/array.rs contains a single empty line. The typed N-dimensional array wrapper (NdArray<T>) that should sit above Buffer and provide the primary user-facing Rust API does not exist.

Buffer handles raw bytes, dtype, layout and strides but has no generic type parameter. All methods on Buffer (e.g. as_slice::<T>, get::<T>) require callers to specify the type at every call site. NdArray<T> is the layer that fixes T at construction and provides ergonomic element access, arithmetic operators, and Display.

Minimum scope:

pub struct NdArray<T: Scalar> {
    buffer: Buffer,
    _marker: PhantomData<T>,
}

with Deref<Target = Buffer>, typed constructors (zeros, ones, from_vec), and Index/IndexMut implementations.

File: crates/mohu-array/src/array.rs (currently 1 line)

Signed-off-by: mohu-org atrancendentbeing@gmail.com

[atul-upadhyay-7]

I want to work on this issue

[Mahesh-forcode]

Hi @Bbn08 👋

I'd like to work on this issue as part of GSSoC '26. Could you please assign it to me?

---

My understanding of the problem:

crates/mohu-array/src/array.rs is a single empty line. NdArray<T> — the typed, ergonomic user-facing wrapper above Buffer — does not exist. Every companion module in the crate is also an empty stub:

crates/mohu-array/src/array.rs   // empty
crates/mohu-array/src/iter.rs    // empty
crates/mohu-array/src/shape.rs   // empty
crates/mohu-array/src/slice.rs   // empty
crates/mohu-array/src/view.rs    // empty

Buffer handles raw bytes, dtype, layout, and strides but carries no generic type parameter — callers must specify T at every single call site (buffer.as_slice::<T>(), buffer.get::<T>(), buffer.set::<T>()). NdArray<T> is the layer that fixes T at construction time and turns that untyped substrate into a proper Rust API.

Proposed implementation (minimum scope + immediate adjacents):

array.rs — core struct:

pub struct NdArray<T: Scalar> {
    buffer: Buffer,
    _marker: PhantomData<T>,
}

• Deref<Target = Buffer> / DerefMut so all existing Buffer methods are available on NdArray<T> without re-wrapping.
• Typed constructors — zeros(shape), ones(shape), from_vec(Vec<T>), from_slice(&[T]) — delegating to Buffer::zeros, Buffer::ones, Buffer::from_vec with T::DTYPE inferred from the type parameter rather than passed explicitly.
• Index<&[usize]> / IndexMut<&[usize]> backed by Buffer::get::<T> and Buffer::set::<T>.
• Display showing shape, dtype, and a flat preview of elements (NumPy-style).
• std::ops::{Add, Sub, Mul, Div} delegating to the Buffer::add_scalar / arithmetic methods already present in buffer.rs.

iter.rs — typed iterator:

• NdArrayIter<'a, T> yielding &T by walking the buffer's strides, so for x in arr.iter() works without unsafe at call sites.

view.rs — typed view:

• NdArrayView<'a, T> — a non-owning slice into a parent NdArray<T>, backed by Buffer::slice_axis and Buffer::broadcast_to.

shape.rs / slice.rs — thin newtype wrappers around the existing Layout / SliceArg types from mohu-buffer, re-exported with ergonomic From impls so callers can write arr.slice(s![0..5, ..]) rather than constructing SliceArg manually.

What I won't include in this PR (to keep scope reviewable): SIMD-backed arithmetic, Display for non-contiguous layouts, and Python bindings — those are follow-on work in mohu-simd and mohu-py.

I've read through buffer.rs (full public API), mohu-dtype's Scalar trait hierarchy (Scalar, FloatScalar, IntScalar, RealScalar), and the Cargo.toml dependency graph for mohu-array. The design fits cleanly on top of what already exists. Ready to start immediately upon assignment.

Thanks!

[Muskan23115]

@mugiwaraluffy56 mind if i fix it?

[github-actions]

Assigned to @Pcmhacker-piro ✓

[sudha09-git]

/assign

[github-actions]

This issue is already assigned to @Pcmhacker-piro.