Idea: Describing dynamicly sized types using const generics

[mcy]

@CAD97

• Would using for<..> quantification make more sense over introducing dyn<..> quantification?

For some reason I think this feels wrong. I think, mostly, it's because I don't think it emphasizes that this has a runtime cost. I think I keep wanting fn f(_: for<T: Tr> T); to be a janky APIT. Of course, fn f() -> for<T: Tr> T; makes zero sense for RPIT (for doesn't really yell "existential type" to me...).

[Having mentioned impl Trait I feel vaguely compelled to say something nonsensical like "we should add fn foo() -> impl<const N: usize> [T; impl]", for when you really want to hide the returned const's value...]

[adamAndMath]

@mcy

I feel the need to ask: is this a problem people actually have? I think that we should weigh the value of trying to solve this problem, versus introducing confusing syntax (remember: dyn<> does commute past !CoerceUnsized types, which is definitely a source of confusion).

These things would still be sort of doable in your proposed syntax:

type DualView<'a, const N: usize> = (&'a [T; N], &'a [T; N]);
DualView<dyn usize> = dyn<const N: usize> (&[T; N], &[T; N])
(&[T; dyn usize], &[T; dyn usize]) = (&dyn<const N: usize> [T;N], &dyn<const N: usize>)

I see this as very problematic consequence, as type is supposed to be an alias, and as such should not change behaviour.

@mcy

[Having mentioned impl Trait I feel vaguely compelled to say something nonsensical like "we should add fn foo() -> impl<const N: usize> [T; impl] ", for when you really want to hide the returned const’s value…]

This seems very reasonable to me. If dyn Trait is just a special case that desugers to dyn<T: Trait> T. Then it would be natural to do the same thing with impl.