[lang-team-minutes] Const generics

[nikomatsakis]

AFAIK no there’s no issue with associated consts. Since you can’t have a type parameterized by f64 you can never do something like Foo<T::FLOAT>.

I think the restriction really has to do with “input” types, right? Still, it seems like eventually we are going to want to permit floating point types (and indeed arbitrary types) as the values of constants. It also seems quite natural to me that we would want a very strict notion of equality when it comes to instantiating impls and so forth.

Note that we can be extra conservative around floating point values, in order to sidestep annoying questions like whether two distinct NaN bitpatterns are equal. In particular, we could require that two floating point values are only considered “equal” if they derive from the same constant.

Actually, this is an interesting question. I’m assuming that if you had

const C: u32 = 0;
const D: u32 = 0;

we would want [T; C] and [T; D] to be the same type, right? This isn’t entirely obvious (since you might not want your code to stop working when D changes value, for example), but I think it’s already true anyhow so we can’t really avoid it.

I guess that puts us in a bit of a bind in that one might expect the same behavior with floating point constants (e.g., Foo<C> and Foo<D> are the same type, where C and D have type f32 instead).

Well, maybe it’s trickier than I thought! Still, I imagine we are going to have to cross this bridge at some point. Personally I think I would be inclined to say that two floating point values are considered equal for our purposes if they are bitwise equal or both are NaN (I’m not a floating point expert, but I think that values like 0 and -0 have a unique bitpattern, right?).

[withoutboats]

I think we can punt on this question because the answer is the same as the answer for matching against constants, is it not? That is, we have to decide what to do about floats already, and we’ll just do the same thing there for constant parameters.

[christophebiocca]

(I’m not a floating point expert, but I think that values like 0 and -0 have a unique bitpattern, right?).

Yes: 0000 0000 0000 0000 = 0 8000 0000 0000 0000 = –0

As to treating NaNs as equal at compile time, that’s the opposite of their behaviour at runtime, which might be surprising behaviour? On the other hand NaN as a constant time parameter is not likely to see much use, I would think.

[est31]

Still, it seems like eventually we are going to want to permit floating point types (and indeed arbitrary types) as the values of constants

While I agree with allowing arbitrary types to become values of constants (in fact that would be really awesome!), I think we should require things like Eq to be implemented.

I think floats are far too shaky (inspiration) to be used as const type params. Rust should have a strong type system, where types are unified by applying deltas.

Either way, I don’t want to make this discussion now, right now I would prefer to talk about a very basic version where only integers are supported. We can determine later what to do about other types like floats.

About ; vs ,, the ability to abandon {} which is more of a hack is appaling, but mixing , and ; would not look great imo, and it would also make it possible to confuse ; for some higher level grouping and , for some lower level, like it is in C/C++ (most times its used inside for loops).

Generally, I would really love it if this feature could arrive on stable as early as possible. End of this year is nice, but it would be nicer if it were already stable by that time.

[aturon]

The reason I like the semicolon is that if you see Foo<T, N>, you can’t tell from the use site if T or N are types or consts.

That makes sense, and of course feels familiar from lifetimes, but somehow it doesn’t strike me as so important in this case.

For one, thinking in terms of the “reasoning footprint”, use sites mentioning a type/const variable tend to be close to where those variables were introduced (e.g., struct or impl headers, or on the same line for a fn signature). So you don’t have to hold too much in your head. Also, I find that once a struct takes more than a couple of type arguments, I need to refer to its definition regardless any time I am futzing around with some application. YMMV.

[aturon]

For the record, I would also have preferred if lifetime parameters were introduced as lifetime a and used as just a, in the very same way, without the ticks.

We could probably do something like that backwards-compatibly, and the introduction of const parameters would provide a good impetus for doing so. (We’d then also want to allow type for being explicit about type parameters, and just say that leaving off the qualifier defaults to type, and ' implies lifetime.)

In particular, as we continue to improve elision so that you need explicit lifetimes less often (the lang team has some early thoughts about this), having the explicit syntax become more verbose is not such a big deal.

[nikomatsakis]

the answer is the same as the answer for matching against constants

It doesn’t have to be. I would draw a distinction, since the comparison in one case is happening at compile time (generics) and, in other cases, at runtime (matching).

[nikomatsakis]

Either way, I don’t want to make this discussion now, right now I would prefer to talk about a very basic version where only integers are supported. We can determine later what to do about other types like floats.

Ultimately, I agree with this. No reason to rush into anything.

[withoutboats]

Generally, I would really love it if this feature could arrive on stable as early as possible. End of this year is nice, but it would be nicer if it were already stable by that time.

I want to set expectations realistically here: to stabilize we have an FCP which is usually 6 weeks long, then the feature is in the beta branch, then 6 weeks later its stable. There’s a release on January 4, 2018. Targeting stability in that release, we would need to have decided we want it to be stable by October 12, 2017, less than six months from today.

That would give us 6 months to finish the RFC process, do the implementation, get experience using it, make sure the implementation is solid & not buggy, be comfortable that it is ergonomic and comprehensible, discover edge cases, decide what to do about them, and so on. Realistically that cannot happen for a feature as large as const generics.

It will likely be will be implemented on nightly by some time in fall, but I would expect several quarters from then until the feature is ready to stabilize.

[withoutboats]

As to treating NaNs as equal at compile time, that’s the opposite of their behaviour at runtime, which might be surprising behaviour? On the other hand NaN as a constant time parameter is not likely to see much use, I would think.

Yes; if equality isn’t reflexive, though, you could never call a method on a Foo<NaN>, because it would not be the same type as the Foo<NaN> the method is defined on.

In general its better to think in terms of structural equality (which floats don’t have defined today). That is, would if let NaN = NaN { } enter the conditional? Its not obvious either way, I think. Of course I agree with other posts that this can be dealt with later and separately from const generics.

[eddyb]

It’s worse than that! You can encode non-deterministic computation (or dependent on the host compiler) using float intermediaries, but with only integer inputs and outputs.

The plan to deal with that, in the long term, is to use something like LLVM’s APFloat, either through bindings (@edef has had some success there) or wholly converting it to Rust, which implements IEEE 754 semantics in an arbitrary but host-independent deterministic manner (for a given specific version of the compiler).

Anything less can end up with trivial unsoundness, which we should really avoid. See the related Idris issue (that was prompted by a #rust-offtopic discussion more than a year ago).

What we can, even without a better way to evaluate floating-point operations, is to ban floating-point expressions that appear in a type (e.g. [T; float as usize]) which also refers to const parameters or associated consts/const fn that are type-parametrized (e.g. [T; (C as f64 / 0.0) as usize] or [U; C + (0.0 / 0.0) as usize]).

The reason behind that is that a flawed floating-point computation cannot create unsoundness if it happens only once and you always cache the result. This can be done for all constant expressions, except those that need any parameters in order to be evaluated.

Nothing like that can successfully end up in a type in current Rust, even on nightly, so we wouldn’t be breaking any code if we introduce that limitation.

[withoutboats]

Also, I find that once a struct takes more than a couple of type arguments, I need to refer to its definition regardless any time I am futzing around with some application. YMMV.

What makes this easier for me (I know this is a common pattern) is to give the params consistent names across different impls and types, so R is always the type which implements Resource & S always implements Service and so on. My experience is that once I know “which type” <T, Q, R, S> are all, I can understand the signature pretty okay without referring back. (Of course implied bounds also helps here in making each impl primarily list the new bounds it adds.)

Reading things that way, I think having some notation for ‘threshing out’ the consts and types is helpful. <T, Q, R, S; N, M> just seems mildly more readable to me than <T, Q, R, S, N, M>. But this does seem like YMMV, and I think other people (validly) interpret the ; in connection to its semantics in other contexts & other languages.

[comex]

FYI: The questions about floats here seem related to the question of whether to allow matching on floats. That was originally allowed, but is currently being deprecated:

Issue: Tracking issue for `illegal_floating_point_constant_pattern` compatibility lint

[mystor]

I understand the reason why it seems silly to use ; to separate the type and const generics. That being said, I do like the idea of being able to write syntax like:

struct S<T, U=i32; V: usize, W: usize = 10> { ... }

impl<T; V: usize> S<T; V> { ... }

It seems elegant to

a) Allow for const parameters to easily at all places where they are defined or used be separated from type parameters and lifetime parameters b) Follow the same syntax as [u8; 10] (although I don’t really care about that that much) c) Allow both optional const and type parameters separately.

I’m not super picky though, although I don’t like the idea that you wouldn’t be able to have a optional type parameter if you have a const parameter, which enforcing the order without ; would require.

[withoutboats]

I think what would mitigate the ‘kind apparentness’ issue is not only having a SHOUTY_SNAKE_CASE style preference, but also a strong style preference for making const params actual words, instead of single character identifiers. I think this is a good idea regardless, since const params will be fewer in number and more narrowly ‘meaningful’ in the sense that they can operate at the value level.

For example, we should be talking about [T; LEN] instead of [T; N]. Given a BindClient<T, KIND> its sort of obvious that T is a type and KIND is a const if people abide this style recommendation.

I still kind of want to have the semicolons if we do this, but I can accept not having them if that’s the majority preference.

@mystor We should be checking for omitted defaults in a context in which we know the kind (lifetime, type, or const) of each parameter; for that reason we can always figure out which types are missing instead of just which params (of any kind) are missing.

[Uther]

The reason I like the semicolon is that if you see Foo<T, N>, you can’t tell from the use site if T or N are types or consts. Today, lifetimes are distinguished at the use site through the ’ syntax. The semicolon helps make that distinction.

This is not really a problem if the convention is to have lower case name for consts. I don’t think shouting snake case make sense for const parameter (I’m not sure it make sense for normal const anyway but that’s another topic).

IMO const parameters are different from normal const : they are not as much ‘constant’ since they are ‘parameters’ : they vary for every use. The ; would solve the problem only in the declaration anyway. Since generics are usually one letter long, they would be easily mistaken for types at first sight in the implementation too. It make much more sense to me to visually see const parameters the same way as immutable variables.

[nikomatsakis]

I think what would mitigate the ‘kind apparentness’ issue is not only having a SHOUTY_SNAKE_CASE style preference, but also a strong style preference for making const params actual words, instead of single character identifiers. I think this is a good idea regardless, since const params will be fewer in number and more narrowly ‘meaningful’ in the sense that they can operate at the value level.

Just as a data point, in Rayon I used to use words for type parameters (e.g., ITEM instead of T), but this was eventually removed. It’s worth looking over the PR just to get a feeling for what generic code with UPPERCASE_WORDS looks like. (I have mixed feelings about changing to single letters; but I’ll note that I did try SnakeCase as well and I found that actively confusing, since it was hard to distinguish type parameters from actual types.)

[petrochenkov]

Just as a data point, in Rayon I used to use words for type parameters (e.g., ITEM instead of T), but this was eventually removed.

My first impression from looking through the diff - huge regression in readability.

Maybe it’s not so noticeable if you are the code author and know it by heart, but these kind of things are very important when you see the code first time in you life and need to fix it urgently (for some reason this happens with me all the time at work :().

(ALL_CAPS types were strange though, I’d use SnakeCase as usual for types.)

[matthieum]

I agree with you that lower-case for constants would make distinguishing types and constants a non-issue.

However, it would make using existing const values, which have SHOUTY_SNAKE_CASE, inconsistent.

The problem is not so much the declaration site as it is the use site: in the use site you have to use an existing constant, and constants today are SHOUTY_SNAKE_CASE.

I’d be in favor of moving away from this constant style toward regular snake_case (I really don’t see the point of distinguishing them so), but that should be a separate RFC, and seems pretty annoying at this point.

[Ixrec]

I’m also weakly in favor of not using SHOUTY_SNAKE_CASE for constants, mostly because in my C++ world shouty snake case is not used for constants, it’s used for macros. To me that usage is as much a warning as it is a disambiguator, and neither Rust macros nor const generics are features that inherently require a warning the way C++ macros are. For me actual constants have always been camel case and I can’t recall it causing any ambiguity problems. While I do use all caps for my type parameters, my type parameters are usually 1-3 letters and never multiple words, so it doesn’t really feel like shouty snake case.

I was on the fence about semicolon-as-kind-separator for a while, but I think I’m convinced now that I’d rather not imbue the semicolon with that special meaning. It doesn’t even work in the single parameter case, there’s a risk of not composing well/being consistent with other kinds, it can’t do nearly as much to disambiguate which parameters are which as good names and a standard style could (both of which are probably mandatory with or without the semicolon rule), I don’t see a need to forbid parameter lists like Foo<T1, LEN1, T2, LEN2>, and perhaps most importantly, it feels largely orthogonal to everything else being proposed (unlike the curly braces syntax).