Transition to using min_const_generics for user-facing type-level numbers about dialectic HOT 14 CLOSED

It was much easier to change Continue than I thought. Should have this PR together and ready for review in the next day or two.

from dialectic.

Regarding the ToUnary trait, this is how it seems like it must be defined. There must be a wrapper type Number to convert from the land of constants to the land of types; you can't directly implement a trait on a constant:

pub trait ToUnary {
    type AsUnary: Unary;
}

struct Number<const N: usize>(PhantomData<[(); N]>);

impl ToUnary for Number<0> {
    type AsUnary = Z;
}

from dialectic.

Also, seems like the timeline for min_const_generics stabilization is farther out than we thought? Need more info about that.

from dialectic.

As we've confirmed that min_const_generics will hit stable on 2021-03-25, it seems likely that we'll be preparing for a release 0.4 on or slightly after 2021-03-25, using the new feature to improve the user-facing API. Since we're now on board this conversion, there's an important question that needs to be answered: should Continue<N> have N be a const generic, or be a unary type? If we make it a unary type, then we can leave codegen in the macro compiler unchanged; if we instead have a Continue_<N> or UnaryContinue<N> which takes an N: Unary rather than const N: usize, and then have a type synonym pub type Continue<N> = Continue_<<Number<N> as ToUnary>::AsUnary>; then the user-facing API can nicely use Continue<1>, Continue<0>, etc. while having the unary continue exist under the hood.

from dialectic.

Choosing to leave it as unary means that error messages will mention fully-expanded unary numbers, which I think is less intelligible than mentioning constants. Given that we are merely emitting a token stream, I don't think it should be a problem to emit a numeric token in the correct position, should it?

from dialectic.

This is true, but if we emit unary type level integers we could avoid modifying the codegen significantly and also possibly speed up compilation a tiny bit by not putting the onus on Rust to convert the constants into type-level unaries.

from dialectic.

On second thought, I don't think the performance gain from that would be significant. We could find out, but for now I'll emit integers and swap Continue completely over to using const usize.

from dialectic.

Actually, it gets worse. Continue has type-level addition/similar operations performed directly on it. We could convert const generics to unary and then perform the ops and then go back with another trait conversion, but this is all starting to feel a lot like basically just bandaging over the fact that const generics are not ready for arbitrary usage like this yet. We can totally use them for user facing stuff but once we convert to unary, we really don't want to go back if we can avoid it, I think.

from dialectic.

Could we not relatively easily generate impls for a FromUnary trait alongside those for the ToUnary trait, just as we need to generate both List and Tuple to get both directions for tuple-to-list conversions?

Another note: we shouldn't forget to seal the ToUnary (and if implemented, FromUnary) traits.

from dialectic.

So, we can, but there's a couple glitches in that; at the type level, we cannot go from some type containing a const N: usize without binding it to a type variable, and then "solving" for it. The main issue with this is that it is not possible to uniquely specify a const generic parameter without having it in the type being implemented for (trait or non-trait impl.) Const generics cannot be produced from type families. This is annoying.

One possible workaround is not to have Continue<const N: usize> but Continue<Number<N>>, and since Number<N> is of the type kind rather than the const generic usize kind, we can treat it w/ a type family (and we could also potentially have an Indexed trait that produces a Number<const N: usize> from a type implementing it.) I would just like to note that every time we end up doing something that modifies a Continue, we'll end up going from const to Unary to const again. That feels very hacky but I guess it's just the machinery needed to work around the current drawbacks of const generics.

from dialectic.

Perhaps we can defer this to last, since these modifications are independent of all others? I think I have some ideas of how to have and eat our cake simultaneously here, but it will require some experimentation. In general I think it is better to have a more complex internal implementation if it improves error messages. I don't think we need to worry about compile times for the conversions, because since they are non-recursive, each conversion is approximately constant time in the size of the number.

from dialectic.

Defer which to last, the Continue changes? Point taken on the compile times.

from dialectic.

That's right—defer the Continue change to last, since it will likely be the most tricky, and nothing else depends on it.

from dialectic.

Well, I have the rest implemented for the most part, minus the syntactic changes for macros. Other things currently do depend on what Continue uses, such as the macro compiler which currently emits unary integers.

from dialectic.