Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

core::str::Str.as_slice() should be renamed as_str() #14433

Closed
lilyball opened this issue May 26, 2014 · 18 comments
Closed

core::str::Str.as_slice() should be renamed as_str() #14433

lilyball opened this issue May 26, 2014 · 18 comments
Assignees
@aturon
Labels
I-needs-decision Issue: In need of a decision.
Milestone
1.0 beta

Comments

@lilyball
Copy link
Contributor

The method as_slice() in the core::str::Str trait should be renamed to as_str(). This avoids the name collision with core::slice::Vector.as_slice() for types that need to implement both Vector and Str (as I believe Vec<Ascii> should).

I'm filing this issue now to give a chance for anyone to suggest any reasons why this is a bad idea. Otherwise I will go ahead and make the change myself.
@richo
Copy link
Contributor

richo commented May 26, 2014

I'm working in this general direction with my string refactoring
On 25/05/2014 7:13 pm, "Kevin Ballard" [email protected] wrote:

The method as_slice() in the core::str::Str trait should be renamed to
as_str(). This avoids the name collision with
core::slice::Vector.as_slice() for types that need to implement both
Vector and Str (as I believe Vec should).

I'm filing this issue now to give a chance for anyone to suggest any
reasons why this is a bad idea. Otherwise I will go ahead and make the
change myself.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14433
.

@AdamCanady
Copy link

I can make this change since it looks like it still needs to be complete?

@huonw huonw added the A-libs label Sep 7, 2014
@huonw
Copy link
Member

huonw commented Sep 7, 2014

cc @aturon

@Manishearth
Copy link
Member

I don't mind working on this if it needs to be done.

@aturon
Copy link
Member

aturon commented Sep 8, 2014

@Manishearth this will likely be done as part of the API stabilization for strings, which should be wrapping up this week.

@richo
Copy link
Contributor

richo commented Sep 10, 2014

I started on this but it's more work than I expected. I'll do something automated if noone beats me to it.

richo added a commit to richo/rust that referenced this issue Sep 11, 2014
@richo
rename String::as_slice() to String::as_str()
73b7912 
This closes rust-lang#14433

[breaking-change]
@richo richo mentioned this issue Sep 11, 2014
Closed
@japaric
Copy link
Member

japaric commented Nov 4, 2014

@aturon Should this still be done for consistency?

There are still a bunch of as_slice (a lot of them in assert_eq!s) in the rust repo, but those are likely to disappear now that we can use &*string/string[], and in the future string == "foo". So, if we want to do this, I think it makes sense to do it after we remove all those as_slices, to reduce the amount of work.

@aturon
Copy link
Member

aturon commented Nov 4, 2014

@japaric Yes and yes. This has been waiting a bit while the ergonomics for as_slice were improved.

(Also, in general we haven't done API stabilization for str yet.)

@richo
Copy link
Contributor

richo commented Nov 4, 2014

I still have the machinery to do this kicking around somewhere from last time.

iirc, my last PR got closed with something like "not yet", say the word and I'll reopen.

@aturon
Copy link
Member

aturon commented Nov 4, 2014

@richo Awesome, and thanks for your patience!

@richo
Copy link
Contributor

richo commented Nov 4, 2014

No stress. (Thanks for dealing with my often stream of consciousness issues and PRs!).

Should I take it that this is worth doing now or wait for the next meeting?

@aturon
Copy link
Member

aturon commented Nov 4, 2014

@richo Let me discuss the staging with the team and get back to you.

@steveklabnik
Copy link
Member

Traige: this is still true today

@richo
Copy link
Contributor

richo commented Feb 15, 2015

Offer to do it stands

@aturon
Copy link
Member

aturon commented Feb 16, 2015

Nominating for 1.0-beta P-backcompat-libs.

@pnkfelix
Copy link
Member

1.0 beta, P-backcompat-libs, I-needs-decision.

@pnkfelix pnkfelix added this to the 1.0 beta milestone Feb 19, 2015
@pnkfelix pnkfelix added I-needs-decision Issue: In need of a decision. and removed I-nominated labels Feb 19, 2015
@richo richo mentioned this issue Feb 20, 2015
Merged
@nikomatsakis
Copy link
Contributor

Annoyingly, I can't assign this to @richo, but it seems he's got it under control (thanks!). So let this serve as an "assignment" :)

aturon added a commit to aturon/rust that referenced this issue Mar 23, 2015
@aturon
Add generic conversion traits
08ee682 
This commit:

* Introduces `std::convert`, providing an implementation of
RFC 529.

* Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all
in favor of the corresponding generic conversion traits.

  Consequently, various IO APIs now take `AsRef<Path>` rather than
`AsPath`, and so on. Since the types provided by `std` implement both
traits, this should cause relatively little breakage.

* Deprecates many `from_foo` constructors in favor of `from`.

* Changes `PathBuf::new` to take no argument (creating an empty buffer,
  as per convention). The previous behavior is now available as
  `PathBuf::from`.

* De-stabilizes `IntoCow`. It's not clear whether we need this separate trait.

Closes rust-lang#22751
Closes rust-lang#14433

[breaking-change]
@aturon aturon mentioned this issue Mar 24, 2015
Closed
@aturon aturon closed this as completed in 8389253 Mar 24, 2015
@richo
Copy link
Contributor

richo commented Mar 24, 2015

\o/

@axil axil mentioned this issue Aug 21, 2019
Closed
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
@bors
Auto merge of rust-lang#14433 - hecatia-elegua:alias-based-completion…
265f830 
…, r=Veykril

Add doc-alias based completion

Closes rust-lang#14406.

I adapted the parsing code from the CfgExpr parsing code, maybe there's a better abstraction for both, or attribute parsing in general. It also includes `doc(hidden)`-parsing, which means it could replace the other function.
There are a few tests for parsing.

`process_all_names` changed the most, I added some docs there to explain what happens.

Many call sites just pass an empy vec to `add_path_resolution`'s `doc_aliases`, since either it doesn't make sense to pass anything (e.g. visibility completion) or I don't know where to get them from. Shouldn't really matter, as it will just not show aliases if the vec is empty and we can extend alias completion in these cases later.

I added two tests in `special.rs` for struct name completion (which was the main thing I wanted). I also tried function and field names, but these don't work yet. I want to add those in a follow-up PR.
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 5, 2023
@bors
Auto merge of rust-lang#14513 - hecatia-elegua:alias-based-completion…
420a038 
…2, r=Veykril

doc(alias)-based completion round 2

Follow-up on rust-lang#14433
We can now complete fields, functions and some use/mods.
Flyimports don't behave, I don't really have the time to understand the structure there either.
While reading the flyimport code, I removed one method only used there, the closure-tree was a bit confusing, I can revert that if you want.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aturon aturon

Labels
I-needs-decision Issue: In need of a decision.
Projects
None yet
Milestone
1.0 beta
Development

Successfully merging a pull request may close this issue.

Rename to as str richo/rust
Add generic conversion traits aturon/rust
10 participants
@lilyball @steveklabnik @nikomatsakis @pnkfelix @richo @aturon @huonw @Manishearth @AdamCanady @japaric