Skip to content

Conversation

Fili-pk
Copy link

@Fili-pk Fili-pk commented Apr 8, 2024

I removed non-empty restriction. It is breaking change!

@dzmitry-lahoda
Copy link
Contributor

i guess it may be possible with this support both empty and non empty in same codebase based on proof #30

@Fili-pk
Copy link
Author

Fili-pk commented May 9, 2025

You are right. I thought this project is dead so i created similar lib that utilizes const checks. https://gitlab.com/fili_pk/bounded-vector

@Fili-pk
Copy link
Author

Fili-pk commented May 9, 2025

Ok, now it should be non breaking.


/// Returns the last and all the rest of the elements
pub fn split_last(&self) -> (&T, &[T]) {
const { assert!(L != 0) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

crazy. need to change my pr to this if that works. like if assert does create new type constraint, also being just const assert.

@dzmitry-lahoda
Copy link
Contributor

i tried to do this (as in PR):

struct X<const A: usize>;

impl<const A: usize> X<A> {
    const QWE : () = {
        assert!(A > 0);
        assert!(A != 0);
    };
    pub fn new() -> Self {
        const { assert!(A > 0) };
        const { assert!(A != 0) };
        Self
    }
}

impl X<0> {
    pub fn new() -> Self {    
        Self
    }
}

and got

error[E0592]: duplicate definitions with name `new`
  --> src/bounded_vec.rs:21:5
   |
21 |     pub fn new() -> Self {
   |     ^^^^^^^^^^^^^^^^^^^^ duplicate definitions for `new`
...
29 |     pub fn new() -> Self {    
   |     -------------------- other definition for `new`

My assumption that first and first in both vectors should be named same, but different return parameter.

@Fili-pk
Copy link
Author

Fili-pk commented May 9, 2025

Const assert it not type constraint. But it gives compiletime error if lib user use it wrongly. For that you need const generic expressions i think.

@dzmitry-lahoda
Copy link
Contributor

So added here empty vs not #31

@dzmitry-lahoda
Copy link
Contributor

@sethdusek i propose to close this in favor of #31

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants