Join GitHub today
RFC: Collections reform #235
This is a combined conventions and library stabilization RFC. The goal is to establish a set of naming and signature conventions for
The major components of the RFC include:
A big thank-you to @Gankro, who helped collect API information and worked through an initial pass of some of the proposals here.
I skimmed/skipped the first 1000 lines assuming it hasn't changed much since last I saw it. Overall I'm a big
@Gankro I addressed the various typos you pointed out.
I don't think methods like
That said, we could consider using
That's certainly doable. It's a tradeoff, since it makes the API somewhat more complex for a pretty rare use case.
My plan for key recovery was to go through your collection view's RFC, which offers a bit more of a swiss army knife for working with maps. We'll have to think about sets, though.
referenced this pull request
Sep 11, 2014
It seems to me that it would be more flexible to define
(I'm not 100% clear about the rules for blanket
Now if you define a custom string type, you can still get the benefits of
It also would let you have
And you can still define
Did you consider implementing
I want to like the idea of
Hmm, this just occurred to me. The proposal states we would "deprecate" the traits. Is this intended literally (as in #[deprecated]), or will they just be removed overnight? Due to naming conflicts I'm pretty sure that the traits can't coexist in a deprecated form with the proposed concrete impls.
Or will we have a brief period where the traits are deprecated as a warning, with no (merged) replacement?
One thing I keep remembering and forgetting, and don't really know where to put it, so I'm just going to put here since it's relevant to this work:
Instead of all this
This iterator should be DoubleEnded and therefore reversible. This of course doesn't address the inclusive/exclusive scenario, for which we can either do the same thing as
which is the solution I prefer.