Can the stdlib sort a slice of types? | Zig Programming Language | Page 1

red rune Sep 7, 2023, 9:55 PM

#

There's something I'm not understanding about how comptime sometimes is an attribute describing a value (like comptime var x: u8 = 2) and how sometimes the fact that something exists at comptime makes its way into the type signature (like how fn (x: u8) void and fn (comptime x: u8)) are two completely different types.

Using insertion sort as an example, it has a signature like

pub fn insertion(
    comptime T: type,
    items: []T,
    context: anytype,
    comptime lessThanFn: fn (@TypeOf(context), lhs: T, rhs: T) bool,
) void {

Since this signature doesn't include a "comptime" indication on lhs and rhs, the comparator likewise cannot have that indication. Conversely, types as arguments are mandated by the language to be tagged as comptime. I can write fn typeLessThan(_: void, comptime lhs: type, comptime rhs: type) bool, but the compiler will not accept fn typeLessThan(_: void, lhs: type, rhs: type), even when I intend to run insertion sort at comptime. Since the latter can't exist and the former doesn't match the signature required by insertion, it seems impossible to sort in that way.

Is that kind of limitation intentional? It seems on the surface to mandate that you have two versions of many useful functions. How muchof the language breaks if when running a piece of code at comptime that particular distinction is elided?

lapis chasm Sep 7, 2023, 10:14 PM

#

comptime values can be demoted to runtime values, runtime values cannot be promoted to comptime values
comptime parameters cannot be demoted to runtime parameters, runtime parameters can be promoted to comptime parameters

#

so fn (@TypeOf(context), lhs: T, rhs: T) bool can be called at comptime just fine

red rune Sep 7, 2023, 10:37 PM

#

fn (@TypeOf(context), lhs: T, rhs: T) bool can indeed be called at comptime just fine, but I can't construct a fn (@TypeOf(context), lhs: T, rhs: T) bool when T==type because the compiler forces you to instead have a signature of fn (@TypeOf(context), comptime lhs: T, comptime rhs: T) bool

lapis chasm Sep 7, 2023, 10:39 PM

#

ah, slice of types, no, you can't sort it using the stdlib afaik

#

thats a weird edge case

red rune Sep 7, 2023, 10:40 PM

#

Yeah, slice of types.

whole sparrow Sep 7, 2023, 10:40 PM

#

you could sort an array of structs containing the data you want compared and the original index

#

its a bit convoluted tbf

lapis chasm Sep 7, 2023, 10:41 PM

#

whole sparrow you could sort an array of structs containing the data you want compared and the...

a struct with a type field is still comptime only

red rune Sep 7, 2023, 10:41 PM

#

Yeah, there's no way to get that into the ctx right?

#

Guess you could probably do some comptime_var magic to let a "runtime" function access comptime data

whole sparrow Sep 7, 2023, 10:42 PM

#

lapis chasm a struct with a type field is still comptime only

i meant like if you want to sort int types by how many bits they have you can do

const SortThing = struct { bits: usize, original_index: usize };

lapis chasm Sep 7, 2023, 10:42 PM

#

I mean, you can totally pass the slice of types as the context and sort the list of indexes into that slice

red rune Sep 7, 2023, 10:42 PM

#

I literally just want to sort the types (don't even care by what, so long as it's stable) to canonicalize a separate thing being memoized.

#

You can't pass the slice of types as the context can you? Doesn't that have to be comptime?

lapis chasm Sep 7, 2023, 10:43 PM

#

no idea

#

I don't see why you couldn't

#

if that doesn't work, nothing will

red rune Sep 7, 2023, 10:45 PM

#

Oh neat, that does the trick. I suppose anytype is doing the heavy lifting?

lapis chasm Sep 7, 2023, 10:45 PM

#

yeah

red rune Sep 7, 2023, 10:45 PM

#

Weird that you can also have a comptime anytype and have it behave differently.

#

Like the comptime isn't required in that case.

#Can the stdlib sort a slice of types?