Use in constant expressions

[kvark]

It would be useful to be able to use SmallVec in constants (long shot - having BigInt with associated constants for ONE, ZERO, etc). This would require exposing SmallVecData enum. Any concerns/objections?

[gnzlbg]

I think this is generally desired, but the only issue blocking this right now are the current limitations of const fn.

[kvark]

@gnzlbg well, I was thinking if it's possible to provide this ability without const fn. I.e. if SmallVecData is exposed, the user could provide it manually.

[mbrubeck]

Unfortunately, that would also require making the fields of SmallVec public, which would break the encapsulation necessary for memory safety. I think the only way we can do this soundly is with const fn.

[gnzlbg]

@kvark

I was thinking if it's possible to provide this ability without const fn

Ah, I see. The answer is that it is not possible to do this "right" without const fn. A solution could be hacked, but that's not really worth doing.

Also, what are you trying to do? This sounds a lot of like XY.

[kvark]

@gnzlbg I looked at num-traits crate, and it has quite a few interfaces that should have been const values in the first place. The blocker to convert those is having BigInt as one of the implementations, and it's based on heap allocation. So I was thinking if it's possible to convert BigInt to use SmallVec and have that one supporting constant initialization...

[gnzlbg]

The blocker to convert those is having BigInt as one of the implementations, and it's based on heap allocation. So I was thinking if it's possible to convert BigInt to use SmallVec and have that one supporting constant initialization...

I see. I don't think that's going to be possible for the time being :/

---

Offtopic: Which APIs do you mean? Most of the APIs in num-traits can't be const fn because they are implemented as trait methods, which aren't allowed to be const either. Was your idea to make some of these APIs be associated consts instead?

[kvark]

@gnzlbg

• whole Bounded
• the whole FloatConst thing
• Zero::zero()
• One::one()
• Float::{nan(), infinity(), neg_infinity(), neg_zero(), min_value(), min_positive_value(), max_value(), epsilon()}

[gnzlbg]

That's what I thought. Yeah it makes sense to make those associated const, but for that one would need to add const fn constructors for BigNum as you mentioned. Allowing dynamic memory allocation inside const fn would be enough to allow that, and this is something that miri can already do. There is no need to change the implementation to SmallVec for that. Pinging @oli-obk

(this issue should be closed and that should be discussed somewhere else)

[oli-obk]

I fully agree that we should not modify SmallVec. I definitely plan to push for making most of Vec const fn in 2019, so SmallVec would be trivial after that.