Source
r/rust•
jstrong

current usability of const generics?

I've been on nightly for years but have so far not dipped my toe into const generics. If you've used it recently I'd love to hear about your experience. The current compiler warning that it's an "incomplete feature" scared me off earlier tonight when I would have otherwise used it. On my current project, it's ok to use nightly/unstable features but I can't afford to be slowed down with too many mysterious bugs or compiler crashes. Also, if there are pitfalls to avoid in structuring types that use the new features, that'd be great to hear, too. Thanks!

Posted Apr 30, 2020, 2:54 AM UTC

10
slashgrinplanetkit•

I can't afford to be slowed down with too many mysterious bugs or compiler crashes

There's your answer. There's still a lot of churn in lots of the details behind const generics. If you can't afford to be slowed down by bugs on nightly that come out of that, then you should definitely avoid the feature until it's on stable.

This also applies, albeit to a slightly lesser extent, to any features that haven't yet been stabilized, because there is no guarantee that they won't be, e.g. completely removed overnight. Even if a feature is 99% likely to end up shipping eventually, the implementation might be completely removed if there are problems with it in favor of a new separate implementation that won't land in nightly for weeks or even months.

The point to remember here is that anything at all could happen to unstable features, so don't rely on any nightly features unless you can easily replace your use of them with stable features, or your project can tolerate being held up indefinitely. Anything else is just gambling.

16
jstrongOP•

I get what you're saying, however, I think there's two underlying issues here: how well an existing nightly feature works right now, and its potential future instability. future instability doesn't always matter, e.g. if the code is a prototype or otherwise iterative. for my purposes in asking about this, I don't really care if const generics ceases to exist in four months, but it'd be a big pain if it caused lots of bugs and compiler crashes in the next week for me.

5
Hobofan94leaf · collenchyma•

My personal recommendation (I know a lot of people will disagree): nightly == nightly. If you assume you are working with "more stable" nightly features, you are looking to get hurt. All nightly features are (still) on nightly for a reason, and you should assume bugs will happen.

7
jstrongOP•

I've used a good number of nightly features productively, but only in situations where I'm the only person working on that code. I guess I just see it as requiring a bit of judgement. It's also become a lot less frequent that I need to reach for a nightly feature than a couple years ago. I'm not saying that you're wrong, exactly, just that it doesn't match my experience of using nightly features without it causing me any significant problems. Did you run into something that prompted you to be more cautious about it? Would be interested to hear.

3
slashgrinplanetkit•

Gotcha. So, to clarify, you'd basically be pretty happy to pin to a specific nightly version if the feature works well enough on that one version?

I'm afraid I can't offer any insight into how well const generics work right now and on what use cases. (I played with it briefly once a while ago, but that's it.) Maybe this isn't particularly helpful, but you could try looking at rustc's own test suite for examples of cases that work, and possibly even find some that exist but are commented-out because they don't work yet. Also, there's https://github.com/rust-lang/rust/pull/67890 presumably landing soon-ish, and [EDIT: soon-to-come follow-up work on] that might make some more things work. Again, sorry, I don't actually have any specific insights on any of this; just general commentary. :)

3
jstrongOP•

that's a good idea - appreciate your help!

2
theZcuber•

Try it? Without details about your use case, there's not much more we can say.

5
jstrongOP•

I'm not asking for how to use it for my purposes, I'm asking whether the existing implementation is still buggy, or very nearly there.

2
theZcuber•

Well, that depends. For some situations it's fine, others it's not. That's why the use case matters.

3
jstrongOP•

I was looking to make a struct generic over the length of several array members on that struct that should have the same length.

something like

struct S<const N: usize> {
    a: [f64; N],
    b: [f64; N],
}
2
theZcuber•

Fairly certain simple cases like that work fine.

3
EarthyFeet•

Some envisoned features like expressions will need 10 years to arrive, if I'd wildly guess, and array length support is nearly there now.

0
GuamPirate•

It depends on what you need. If you want to paramaterize a function with some constant, it's almost always sufficient. Otherwise, it's a bit more of gamble

3
jstrongOP•

In this case I was looking to make a struct generic over the length of several array members that should have the same length.

1
est31•

I have an optional const-generics based implementation inside my serde-big-array crate. A few months ago, I wrote the code and fixed all erros I could fix but it didn't work, giving an error instead. I tried it a few weeks ago and now it works.

https://github.com/est31/serde-big-array/issues/3

https://github.com/est31/serde-big-array/blob/0cbd7f38edb2f50ce0d6a9cde8d690ca548d48aa/src/const_generics.rs

1
jstrongOP•

interesting, thanks for sharing!

1