Static assertions + momorphization

language design
1

I've been slowly working my way towards a pre-RFC for letting developers extend the type system through refinement types.

While attempting to find counter-examples to my proposal, I've realized that much of what I'm doing at the moment could be implemented if only we could write things along the lines of:

fn _assert_is_valid<T>(&self) {
   static /* or `const` */_ : () = assert!(Self::some_const_fn<T>());
}

Now, this won't work because each syntactic instance of static is compiled into a single variable, instead of being one variable per monomorphization, so the assertion doesn't have access to T or even Self in the context. This makes sense if one thinks of static as a mechanism to define variables, but less if one thinks of static as a mechanism to run compile-time assertions, and I'm not sure why it makes sense for const at all.

So I wonder if it would make sense to have a variant of static or const that:

  1. could never be used to define a new variable (so, basically restricted to passing/failing at compile time);
  2. would be computed after monomorphization.

Is there anything in the language that would block such a feature?

1 Like
2

I've been slowly working my way towards a pre-RFC for letting developers extend the type system through refinement types.

You may want to look into the pattern types initiative.

I'm pretty sure that const blocks should work for this

const {
    assert!(...);
}
7 Likes
3

They do, thank you very much!