pre-RFC `const` function arguments

[leonardo]

This restriction can be analogized to the restriction on using type variables in types constructed in the body of functions - all of these declarations, though private to this item, must be independent of it, and do not have any of its parameters in scope.

D language has templates more like C++, and it allows all that code:

void foo(size_t x)() {
    enum size_t y = x * 2;
    static size_t[2] z = [x, x];

    struct Foo {
        int[x] arg;
    }
}
void main() {
    foo!5();
}

[gnzlbg]

The RFC2000 discusses this in detail: it mentions allowing that as an extension, and it discusses why it doesn’t do so initially. I’d recommend reading the RFC2000 and its PR for context.

Adding that feature in the future would mean that it becomes usable with const function arguments as well, but I would prefer if this thread does not become the place to discuss doing that. This RFC focuses on a different issue.

[leonardo]

Yes, sorry for overriding your thread. I remember Walter Bright trying to implement your idea in the D language (enum function arguments) and failing.

[gnzlbg]

Bright trying to implement your idea in the D language (enum function arguments) and failing.

That’s interesting, do you have links or context that explains why, or do you happen to know what the issues are? D is a completely different language, so maybe what applies to D does not apply to Rust, but learning what failed there might help.

[leonardo]

D isn’t a completely different language, despite D and Rust generics have a different design (you can add constraints to the type arguments of D generics, but the compiler doesn’t enforce they are sufficient for their successful compilation, and the exact template code is verified only at instantiation time). But I agree that the D compiler is quite different from the Rust compiler so probably there’s no insight that Walter failure for Rustc.

I have failed finding the D thread, it’s an old one and the forum have moved several times, lot of stuff could harder to find.

I vaguely remember Walter failed because there was too much mixing between run-time and compile-time stuff. I suspect the problem was similar of having the ctfe boolean variable (that’s true in a function if that function is run at run time) as enum instead as a run-time variable.

Walter tried to implement this idea for ergonomic reasons similar to yours, that is to make D templates “more human”.

Elsewhere I have suggested to introduce in Rust (and D) a feature similar to Ada 2012 Static_Predicate: http://www.ada-auth.org/standards/12rat/html/Rat12-2-5.html

Perhaps your idea could be used/adapted to implement that feature…

[comex]

As an interesting data point:

Swift doesn’t support const generics, but even for type parameters, it has a mechanism specifically to avoid the need for explicit function specialization (i.e. turbofish), which it doesn’t support at all.

For example, to do the equivalent of transmute, you can write:

let transmuted = unsafeBitCast(foo, to: Int32.self)

The unsafeBitCast function is declared as

public func unsafeBitCast<T, U>(_ x: T, to type: U.Type) -> U

This works because Int32.Type is a singleton type with Int32.self as the sole instance (and that works for any type). However, it requires some special-casing, because T.Type looks like an associated type, but normally you can’t do type inference backwards from an associated type to the base type. (Associated types in Swift have similar semantics as in Rust.) And for that matter, I find it a bit strange: why can’t you just write to: Int32? In Rust, the reason you can’t just write a type in expression position is to avoid parser ambiguities with angle brackets, but adding .self at the end doesn’t help with that (and Swift has a different solution to the angle bracket issue).

But anyway, you can see how it’s nice to put generic parameters into the regular flow of function arguments, allowing for a more natural ordering. Swift probably benefits more from this than Rust would, due to its pervasive use of argument labels - i.e. cast(value, to: Type) clearly flows better than cast<Type>(value), but you couldn’t say the same for cast(value, Type). Still - getting back on topic - when it comes to value parameters (const generics), I think there are more cases where it would be useful.

[withoutboats]

I think I’d like to see const generics implemented before we talk about sugaring them.

[ubsan]

we can make the point that const in Rust is equivalent to constexpr in C++ (mostly) - i.e., what const should have meant . It’s also not on the type, it’s on the binding, which should make it more obvious.

[gnzlbg]

That’s fair. I submitted this pre-RFC for two reasons:

• const generics aren’t implemented yet, and if this is something that we’ll eventually want to pursue then maybe those implementing const generics should be aware of it and raise issues about it while implementing const-generics (instead of x time later when nobody remembers the gory implementation details).

• there is a stopgap solution (the PR @kennytm mentioned) being merged into master as we speak, and that is part of a feature (SIMD) that should be part of the Rust 2018 epoch (that is, it will become stable some time earlier this year). When adding stopgap solutions to language limitations that will surface in the API of std library functionality that will become stabilized “soon”, I think that it makes sense to at least explore in a pre-RFC form what that stopgap solution would look like if it were turned into a “real” language feature. Mainly to be sure that we don’t stabilize a stopgap that can’t either be replaced by something better in the future, that is completely broken by design, or that prevents us from doing the right thing in the future.

Does this make sense?

[Centril]

To me, const generics are about lifting values (const values in this case) to the type level (i.e: dependent types). If const generics are permitted within (args) of function application fun(args), then so should other type level arguments. So for the function definition fn identity<T>(x: T) { x } the call identity(u8, 1u8) would be permitted as the equivalent of identity::<u8>(1u8). Anything else would be inconsistent to me. So I’m currently against this proposal.

[gnzlbg]

If const generics are permitted within (args) of function application fun(args), then so should other type level arguments

For lifetime parameters one does not need to use < >:

fn foo<'a>(x: &'a i32) {}
// can be written as just:
fn foo(x: &i32) {}

For type parameters RFC1951: universal impl Trait was merged. This works today:

#![feature(universal_impl_trait)]
use std::fmt::Display;
// This is just another way of writing
// fn foo<T: Display>(x: T);
fn foo(x: impl Display) { println!("{}", x) }
fn main() { foo(0); }

That is, the language can already do this in “some form” for both lifetimes and types. Obviously, types are not lifetimes, so the features for types and lifetimes are necessarily different. In both cases you can “pass” types and lifetimes via (args...) without turbofish by leveraging type deduction and lifetime inference. const are neither types nor lifetimes, so allowing something like this for consts would probably work differently as well.

This RFC proposes one possible way of doing this for consts, like we can already do for both types and lifetimes.

If const generics are permitted within (args) of function application fun(args), then so should other type level arguments. […] Anything else would be inconsistent to me. So I’m currently against this proposal.

This proposal does not preclude adding those as a future extension in any way. If you feel strongly about those, write RFCs for them.

FWIW I think that an all-or-nothing mentality is not, in my opinion, very useful when discussing language improvements. Most language improvements that are actually merged are minimal incremental improvements over what’s there. To me it is more useful to know whether this a direction in which we want Rust to go? Whether this is a step in that direction? Whether this is “the right step”? Whether this step prevents other steps that we might want to take? Etc.

[Centril]

For lifetime parameters one does not need to use < >:

AFAIK, not only are you not required to specify lifetimes in turbofish, you are not allowed to do so at all.

You also do not need to specify type arguments in turbofish in a majority of cases - but are permitted to do so, and I suspect this holds for const in a type level context in some cases as well (whether this is in the minority or majority it is too early to tell…).

I don’t see how this argument about inference has any bearing on whether you should be able to move (some, specifically const) type level arguments from the type application site (turbofish site) to the value application site.

For type parameters RFC1951: universal impl Trait was merged.

impl Trait in argument position provides for anonymous universal quantification, it does not permit you to specify the specific type of x in x: impl Display when calling foo, the type must (currently) be inferred.

const are neither types nor lifetimes

To me, const in const generics are types (or they would at least be so in Haskell with DataKinds).

This proposal does not preclude adding those as a future extension in any way. If you feel strongly about those, write RFCs for them.

I should have clarified this part. My preference is that we not move in this general direction at all, so I won’t write such an RFC. I think the separation between values and types is a good thing and I don’t want to set precedent that changes this.

FWIW I think that an all-or-nothing mentality is not, in my opinion, very useful when discussing language improvements.

I agree, up to a point. I think we should think about what precedent certain changes set and what the “future work” might be. Having a coherent story is essential in language design.

[gnzlbg]

While replying to @centril I asked myself whether this can be considered some for of "const inference". It obviously is not: const-functions arguments are an explicit way of passing const parameters:

fn foo(x: [i32, N], const N: usize) { ... }
foo(x, 42);  // OK: equivalent to foo::<42>(x);
foo(x); // ~ERROR: missing const argument N
foo::<42>(x); 
// ~ERROR: missing const argument N
// ~ERROR: const function arguments cannot be passed via type paraments

With this restriction, const-generics are more powerful because if IIUC RFC2000 they allow “inferring” the value of the const:

fn foo<const N: usize>(x: [i32, N]) { ... }
let x: [i32, 42] = ... ;
foo::<42>(x); // OK
foo(x); // OK: N "inferred" to be 42

[gnzlbg]

To me, const in const generics are types (or they would at least be so in Haskell with DataKinds).

IIUC RFC2000 const generics, which I am not sure I do (@withoutboats ?):

Today, types in Rust can be parameterized by two kinds: types and lifetimes. We will additionally allow types to be parameterized by values […]

That explicitly states that const at the type level are not of kind type but of kind value. What RFC2000 does is introduce this new type of kind, and then it allows types to be parametrized by this new type of kind.

So while it might be useful to think of them as “types” they are not, they are values that can be part of a type.

Does this make sense? In any case this discussion is a bit tangential to this RFC I think.

I should have clarified this part. My preference is that we not move in this general direction at all, so I won’t write such an RFC. I think the separation between values and types is a good thing and I don’t want to set precedent that changes this.

I agree. Right now I don’t think I want those other things in the language either. However, I obviously think that the part of that feature for consts stands on its own (or otherwise I wouldn’t be writing this RFC).

I’ve extended the drawbacks section with your concern that this could lead to using types or lifetimes in function argument position just like Swift does. And clarify that this RFC neither prevents those features from happening nor proposes them, but that does not mean that they should be proposed.

EDIT: this is how Swift allows that btw: doSomething(myType: T.self). Named function arguments makes this a bit nicer than how doing something like that would look in Rust night now. But if Rust had named function arguments we might think about this differently.

[Centril]

In any case this discussion is a bit tangential to this RFC I think

Sure, tho I think it is beneficial to hash it out somewhere =)

That explicitly states that const at the type level are not of kind type but of kind value.

I don’t think you can draw the conclusion that "const at the type level are not of kind type" from that quote given that dependent types allow a term to be both a value and a type.

Does this make sense?

From a Haskeller’s perspective, I’d say that RFC 2000 in fact introduces an infinite amount of kinds. Specifically, const generics allow you to promote (const) values to types and types to kinds.

Consider:

enum Max3 { One, Two, Three }

When you say:

const fn foo<const N: Max3> // N is a type, Max3 is a kind
    () -> Max3 { N } // N is a value, Max3 is a type

const N: Max3 = Max3::One;
const M: Max3 = foo::<N>(); // We promote N to a type.

Then Max3 is a kind in the context of <const N: Max3>, and N is a type. Since it is a type promoted from a value, you can also use N at the expression / value level.

Interestingly and on a tangent, Agda allows you to mix things like so:

(A : Set) → (n : Nat) → (u : Vec A n) → (v : Vec A n) → Vec A n

where Set is the type of sets and Vec A n is the type of vectors with n elements of type A.

So your proposed changes make sense to me if we decide to go fully dependent some day. Agda also has implicit arguments which Idris does as well. It might be a good idea to re-interpret turbofish site not as type application site but as implicit argument site which is an argument for your proposed changes.

I’ve extended the drawbacks section with your concern

Cheers =)

[gnzlbg]

Sure, tho I think it is beneficial to hash it out somewhere =)

The proper place would be probably the tracking issue for RFC2000: https://github.com/rust-lang/rust/issues/44580

Then Max3 is a kind in the context of , and N is a type. Since it is a type promoted from a value, you can also use N at the expression / value level.

That does make sense to me. I wish RFC2000 would have had more examples to make these things clearer.

[kainino]

(Warning: Larger wall of text than intended, with some ideas in it. Maybe they’ll serve as inspiration, or more likely I’ve gotten something completely wrong.)

---

Then Max3 is a kind in the context of <const N: Max3>, and N is a type.

I’m having trouble understanding why this makes Max3 a kind (in the Haskell definition of “kind”). It seems to me that Max3 has the same kind as a trait/typeclass - say, std::cmp::Eq. That is, I think the statement T: Eq (the type T is a subtype of the typeclass Eq) is analogous to the statement const N: Max3 (the type const N is a subtype of the typeclass (type) Max3).

(From a purely set-theoretic standpoint, these things are all the same - a value Max3::One is an element of a single-valued set {Max3::One}, which is a subset of Max3 = {Max3::One, Max3::Two, Max3::Three}, which could be a subset of Eq. In that model, n: Max3 is an element n, while const N: Max3 is a single-valued set {N}.)

BTW, in Haskell, the kind of various typeclasses (Eq, Num, etc.) is * -> Constraint (where * is the kind of a type). But since the Constraint type is sort of opaque and I don’t understand it, I don’t know if these really are the same kind.

---

One observation from the above is that there is a one-to-one-mapping between values n: Max3 (n) and their lowest types (consts) const n: Max3 ({n}). We could say that there is an implicit conversion from the type const n to the value n because const n is a subset of {n}. We could also say that a const declaration like const N: Max3 = Max3::One is actually a type declaration, and by extension that a literal Max3::One is actually a type regardless of context.

Given all of this (just when you thought I had long gone off the rails, this is where I tie it back into the original conversation): We could say we are actually already putting types (consts) in value position: f(Max3::One). it seems entirely reasonable, then, to actually constrain an argument to be a type (a further constraint than currently possible):

fn f<const N: Max3>(n: N);

Breaking down the type constraints here:

• const N is a subset of Max3
• n is a subset of const N

GIven an invocation f(Max3::One), the type N could therefore be inferred:

• n is a subset of const N
• n is single-valued
• N is single-valued

Therefore, n == N == Max3::One, so the inferred invocation is: f<Max3::One>(Max3::One).

My conclusion is basically that the function declaration syntax I used seems sensible, and it seems (to me) to tie well back into RFC2000. (Although I’m actually having trouble deciding which of the following makes more sense. It’s late and I have confused myself.)

fn f<const N: Max3>(n: N);
fn f<const N: Max3>(const n: N); // n needs to be const, so that may need to be explicit
fn f<const N: Max3>(const n: const N);

The latter two probably resolve naturally back into the original syntax proposal by contracting the two constraints: fn f(const n: Max3).

[gnzlbg]

So IIUC what you are suggesting is that, instead of what this RFC proposes:

fn foo(const N: usize) { }

the syntax:

fn foo<const N: usize>(const N: usize) { ... }

leveraging “type deduction” (if consts are types) meshes better with RFC2000 ?

If so, I wholeheartedly agree, what you propose:

• 1. Gets the job done:
  • It allows specifying that function arguments must be compile-time constants, solving the problem for SIMD and related interfaces
  • It improves ergonomics by allowing users of functions specified this way to pass constants as foo(2 * N) instead of foo::<{2 * N}>()
• 2. Is a smaller incremental step than what this RFC proposes:
  • It is analogous to how type arguments and type-deduction work today: one can write fn foo<const N: usize>() and force callers to do foo::<{2 * N}>(), but one can also write fn foo<const N: usize>(const N: usize) and allow callers to use foo(2 * N). This looks analogous to fn bar<T>() vs fn bar<T>(x: T).
  • If we wanted (not saying we do), we could still allow fn foo(const N: usize) in the future maybe in a way that is more consistent with universal impl Trait. In any case, we don’t need to do this now

So I think this is a great idea which in retrospect seems obvious. Thanks @kainino !

[gnzlbg]

One general question I have is:

fn foo<const N: usize>(const N: usize) { ... }

Is it a problem (e.g. parsing) that N and const appears twice there, in both type positions ?

[kennytm]

I’m having trouble understanding why this makes Max3 a kind (in the Haskell definition of “kind”). It seems to me that Max3 has the same kind as a trait/typeclass - say, std::cmp::Eq. That is, I think the statement T: Eq (the type T is a subtype of the typeclass Eq) is analogous to the statement const N: Max3 (the type const N is a subtype of the typeclass (type) Max3).

IMO, const is the kind, N is “type” (a member of the kind) and Max3 is the type-class.

Therefore…

the syntax:

fn foo<const N: usize>(const N: usize) { ... }

leveraging “type deduction” (if consts are types) meshes better with RFC2000 ?

to leverage “type deduction” the proper declaration should be

fn foo<const N: usize>(_n: N) { ... }

Compare this with Typescript’s literal types.