profile
viewpoint

japaric/steed 520

[INACTIVE] Rust's standard library, free of C dependencies, for Linux systems

bluss/arrayvec 273

A vector with a fixed capacity. (Rust)

strega-nil/readline 3

A cross platform readline wrapper in Rust (Linux, Mac OS X, and Windows)

tbu-/dirs 3

A library for querying operating system specific directories

tbu-/buffer 2

Safe, write-only, generics-free buffer abstraction

tbu-/file_offset 1

A Rust library for atomically reading and writing files at given offsets

tbu-/movim 1

Movim - Kickass Social Network

strega-nil/readline-sys 0

Declarations for `libreadline` or `libedit`

tbu-/arrayvec 0

A vector with a fixed capacity. (Rust)

tbu-/assert_matches 0

Provides macro `assert_matches` for testing pattern matching

issue openedbluss/arrayvec

Suggested API change

I noticed an API inconsistency. ArrayVec::push panics if you overflow the capacity, but ArrayVec::extend silently drops elements if you overflow the capacity.

I prefer the panicking behavior, since otherwise you run the risk of accidentally losing iterator elements. imo that's not an intuitive failure mode. I'd suggest changing extend to panic on overflow, and introduce a fallible try_extend (after all, you already have try_extend_from_slice), try_from_iterator, and probably try_collect and a trait to go with it.

This is a breaking change. The migration path would be pretty straightforward:

// previous version
arrayvec.extend(iterator);

// next version
arrayvec.extend(iterator.take(arrayvec.remaining_capacity());
// -- OR --
let _ignore_result = arrayvec.try_extend(iterator);

created time in 11 days

issue openedbluss/arrayvec

Safety documentation

I've developed a crate for my bachelor's thesis to make working with unsafe code a little bit safer. It works by annotating unsafe functions with the preconditions that need to be upheld for their safety. A call to an annotated function will fail to compile, unless it is assured at the call site that the preconditions hold. Assuring this uses another attribute at the call site.

Here is the link to the crate: https://github.com/aticu/pre.

If you'd be willing to give it a try, I'd be happy to prepare a pull request to integrate its usage into arrayvec where possible. While adding it, I'd also audit the unsafe usage of arrayvec. Since the crate is not yet 1.0 and you don't want non-1.0 dependencies, I'd add it as a dev-dependency, so these checks are only performed in test builds.

If you're not interested, I'd appreciate it if you could briefly let me know why, as that will be valuable feedback for my thesis.

created time in 20 days

issue commentbluss/arrayvec

A vec! like macro

I think such a macro would be nice, even if the only advantage was that it made arrayvec work more like Vec and SmallVec. This would make it easier to remember how to construct an "ArrayVec literal".

nico-abram

comment created time in 25 days

pull request commentbluss/arrayvec

Add unstable-const-fn feature to make new() functions const.

How far are we from that this is stable?

Not sure.

The trait bounds are a problem aren't they?

Yes.

  • I'd suggest the feature name unstable-const-fn
  • The crate feature must be documented (as unstable) at the top of lib.rs with the other features.
  • The pull request updated with a description

Done.

m-ou-se

comment created time in a month

pull request commentbluss/arrayvec

Make new functions const (gated by feature="const").

Nice that this can be done. How far are we from that this is stable? The trait bounds are a problem aren't they?

I'm not sure we can commit to having unstable features in the crate, but if we could the following remains:

  • I'd suggest the feature name unstable-const-fn
  • The crate feature must be documented (as unstable) at the top of lib.rs with the other features.
  • The pull request updated with a description

🙂

m-ou-se

comment created time in a month

issue commentbluss/arrayvec

Support for constant generics

@Michael-F-Bryan Yes, I think we should, if it makes sense. There might be other crates already filling this need?

c410-f3r

comment created time in a month

issue openedtomprogrammer/rust-ascii

AsciiChar::Caret documentation shows '_'

ascii_char.rs has this typo:

    /// `'_'`
    Caret = 94,

Obviously, that should be '^'.

created time in a month

pull request commenttomprogrammer/rust-ascii

Mark AsciiString::new() as 'const fn'

Thanks, you probably also need to update minimum rust version in documentation and .travis.yml.

@tomprogrammer it looks like travis isn't working?

JOE1994

comment created time in 2 months

issue commenttomprogrammer/rust-ascii

Most functions could be const

AsciiStr::new() was removed so that it can be added back as a const fn when possible without any backwards compatibility restrictions. So if that's possible now then feel free to add it!

PvdBerg1998

comment created time in 2 months

issue commenttomprogrammer/rust-ascii

Most functions could be const

Most AsciiChar methods has been made const fn with version 1.0.0. I figured out that a const fn AsciiChar::new() was possible by indexing into a constant array.

For AsciiStr and AsciiString everything above still holds, so I'm leaving this issue open until they can be created in const contexts.

* [x]  `AsciiChar::new()`

* [ ]  `AsciiStr::new()`

* [ ]  `AsciiString::new()`

It seems that AsciiStr::new() no longer exists as of 1.0.0 :cat2:

PvdBerg1998

comment created time in 2 months

PR opened tomprogrammer/rust-ascii

Mark AsciiString::new() as 'const fn'

Since 'Vec::new()' is already a const function, there is no difference in generated MIR/ASM whether AsciiString::new() is marked const or not. I saw issue #56 is waiting to mark this function as 'const', and this PR simply marks 'AsciiString::new()' as a const fn.

cargo test successfully passed all tests in my local environment.

Thank you for reviewing this PR :smile_cat:

p.s. I compared the generated MIR and ASM from https://play.rust-lang.org with/without const.

// Removing 'const' specifier does not change output of generated MIR & ASM :)
pub const fn new() -> Vec<i64> {
    Vec::new()
}

/* ASM OUTPUT
playground::new:
	movq	%rdi, %rax
	movq	$8, (%rdi)
	xorps	%xmm0, %xmm0
	movups	%xmm0, 8(%rdi)
	retq
*/

/* MIR OUTPUT
// WARNING: This output format is intended for human consumers only
// and is subject to change without notice. Knock yourself out.
fn new() -> std::vec::Vec<i64> {
    let mut _0: std::vec::Vec<i64>;      // return place in scope 0 at src/lib.rs:1:17: 1:25

    bb0: {
        _0 = const std::vec::Vec::<i64>::new() -> bb1; // bb0[0]: scope 0 at src/lib.rs:2:5: 2:15
                                         // ty::Const
                                         // + ty: fn() -> std::vec::Vec<i64> {std::vec::Vec::<i64>::new}
                                         // + val: Value(Scalar(<ZST>))
                                         // mir::Constant
                                         // + span: src/lib.rs:2:5: 2:13
                                         // + user_ty: UserType(0)
                                         // + literal: Const { ty: fn() -> std::vec::Vec<i64> {std::vec::Vec::<i64>::new}, val: Value(Scalar(<ZST>)) }
    }

    bb1: {
        return;                          // bb1[0]: scope 0 at src/lib.rs:3:2: 3:2
    }
}
*/
+1 -1

0 comment

1 changed file

pr created time in 2 months

issue commentbluss/arrayvec

MSRV policy?

Perfect, thanks for the quick response!

jhpratt

comment created time in 2 months

issue closedbluss/arrayvec

MSRV policy?

Hello. I'm looking at using arrayvec as part of no-alloc support in the time crate. What is the policy on bumping the MSRV, if there is one?

closed time in 2 months

jhpratt

issue commentbluss/arrayvec

MSRV policy?

Doc for version is here https://docs.rs/arrayvec/0.5.1/arrayvec/#rust-version

Bumping MSRV is a breaking change in the 0.x, 0.y etc chain of releases, and when we go 1.x it will be the same as indexmap's policy: https://docs.rs/indexmap/1.3.2/indexmap/#rust-version

jhpratt

comment created time in 2 months

issue openedbluss/arrayvec

MSRV policy?

Hello. I'm looking at using arrayvec as part of no-alloc support in the time crate. What is the policy on bumping the MSRV, if there is one?

created time in 2 months

push eventbluss/arrayvec

Paul Kernfeld

commit sha 488efd0b3e8ee7f41606403b3986020e45c7b36c

impl<A: Array> TryFrom<&[A::Item]> for ArrayVec<A> For issue #106

view details

Paul Kernfeld

commit sha 675e992741185ac897010a73ec54a9483da6e919

allow items that implement Clone

view details

bluss

commit sha 4043c58de78646ffdd268155eb8941e57c33dc6b

Merge pull request #159 from paulkernfeld/try-from-slice Implement TryFrom<Slice> for ArrayVec

view details

push time in 3 months

PR merged bluss/arrayvec

Implement TryFrom<Slice> for ArrayVec

fixes #106

+38 -0

4 comments

2 changed files

paulkernfeld

pr closed time in 3 months

issue closedbluss/arrayvec

ArrayVec from slice

How can i create an ArrayVec from a slice? There is no ArrayVec::from(&[T])

closed time in 3 months

cchudant

pull request commentbluss/arrayvec

impl<A: Array> TryFrom<&[A::Item]> for ArrayVec<A>

Thanks! Feel free to ping me, I will inevitably forget to publish a new version

paulkernfeld

comment created time in 3 months

pull request commentbluss/arrayvec

impl<A: Array> TryFrom<&[A::Item]> for ArrayVec<A>

Sure, no problem! I redid it to support Clone.

paulkernfeld

comment created time in 3 months

issue closedbluss/arrayvec

Add benchmarks to readme

Add benchmarks to readme, that shows how it compares to for example the std vec

closed time in 3 months

Luro02

issue commentbluss/arrayvec

Add benchmarks to readme

This is out of scope for the crate, and heavily dependent on situation. If you find real life performance stories, it would be interesting, but microbenchmarks don't tell us so much. thanks

Luro02

comment created time in 3 months

issue closedbluss/arrayvec

Don't care about the array size

I have a public API that needs to take in a ArrayVec as a fixed-size buffer. But sadly (in this case), the ArrayVec is not only generic over the item type, but also over its size. This means, if I (for example) want a ArrayVec of floats without caring about its size, I need to use a generic <A: Array<Item=float>, ArrayVec<A> everywhere. This not only makes code less readable, but also disallows dynamic trait objects if used in there.

I'd like to have the possibility to ask for an ArrayVec<float> without having to care for the size. I made a quick prototype using trait magic:

pub trait ArrayVecDyn<Item>: Deref<Target = [Item]> + DerefMut<Target = [Item]> {
	fn push(&mut self, element: Item);

	unsafe fn push_unchecked(&mut self, element: Item);

	fn clear(&mut self);

	fn remaining_capacity(&self) -> usize;
}

impl<A: Array> ArrayVecDyn<A::Item> for ArrayVec<A> {
	fn try_push(&mut self, element: A::Item) {
		self.push(element)
	}

	unsafe fn push_unchecked(&mut self, element: A::Item) {
		self.push_unchecked(element)
	}

	fn clear(&mut self) {
		self.clear()
	}

	fn remaining_capacity(&self) -> usize {
		self.remaining_capacity()
	}
}

closed time in 3 months

piegamesde

pull request commentbluss/arrayvec

impl<A: Array> TryFrom<&[A::Item]> for ArrayVec<A>

Please write it as fixes #106 - https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

We can implement it with .extend instead, and then it can support Clone. It can be an efficiency trade-off (depending on optimization), but I think aiming for the Clone version is good.

paulkernfeld

comment created time in 3 months

pull request commentbluss/arrayvec

impl<A: Array> TryFrom<&[A::Item]> for ArrayVec<A>

I implemented this using try_extend_from_slice so it requires that A::Item: Copy. It would also be possible to do this so that A::Item only needs to be Clone, not Copy.

paulkernfeld

comment created time in 3 months

PR opened bluss/arrayvec

impl<A: Array> TryFrom<&[A::Item]> for ArrayVec<A>

For issue #106

+24 -0

0 comment

1 changed file

pr created time in 3 months

pull request commentbluss/arrayvec

append and try_append

Good point, but try-extend can be reserved for (Into-)iterators, and we can't handle them all efficiently in one method without an extra trait. Depending on what trait is needed to handle arrays and arrayvecs for try-append, we can decide then.

jmc718

comment created time in 3 months

pull request commentbluss/arrayvec

append and try_append

I'd think try_extend gives a better name.

jmc718

comment created time in 3 months

issue commentbluss/arrayvec

Give ArrayVec a const-fn constructor

Need to think about how to handle the bounds check for new length (what's consistent - probably panic for out of bounds of capacity), other than that, PRs welcome for resize_with

michael-p

comment created time in 3 months

more