Aligned slices are unusable

[ItsMeSamey]

Problem

slices with non-default alignment (like []align(1) u32) can't be used in mem.eql, sort.binarySearch, sort.partitionPoint, sort... and in many others

Proposed solution

add 'Context' variants to these function much like sort.pdqContext
or
make array argument anytype.
or
This could have been solved by #9260

Zig version:
0.14.0-dev.3187+d4c85079c

[andrewrk]

no whining on the issue tracker

[ItsMeSamey]

I didn't mean to to "whine", but to report a legitimate limitation i ran into it here and had to write this which isn't pretty.
It would be nicer if standard library accommodates such use cases

[andrewrk]

why have you opted out of array alignment?

[ItsMeSamey]

If you mean, 'why did i not use default alignment', that is because i'm reading file from disk which is guaranteed (in my use case) to Not be aligned.
Because a file read from disk is being treated as slice of structs and that file has 1 byte header + the array was written as
'packed'.

[andrewrk]

in this case the solution is not to bloat the executable with a bunch of alternate std.mem functions for operating on unaligned arrays, it's to load your data into aligned arrays, or better yet actually parse the file for validity.

looks like another case of the restriction helping you write better code.