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.

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

RFC: replace the type keyword #5752

Closed
thestinger opened this issue Apr 5, 2013 · 6 comments
Closed

RFC: replace the type keyword #5752

thestinger opened this issue Apr 5, 2013 · 6 comments

Comments

@thestinger
Copy link
Contributor

Calling this type is very confusing and has led to many newcomers thinking that it makes a new type when really it's just to save on typing (ha!) by making an alias.

I'm tempted to say it should just be like C++11 where you can do this:

using foo = int;
template<typename T> bar = std::set<T, std::greater<T>>;

If it's not feasible to extend use this way, calling it alias would still really be an improvement.

@metajack
Copy link
Contributor

metajack commented Apr 5, 2013

+1

@bstrie
Copy link
Contributor

bstrie commented Apr 5, 2013

As long as we're bikeshedding type declarations, I want to register that I don't find the different uses of struct to be at all intuitive. For example, I know that "tuple structs" exist, but I honestly couldn't tell you what they are or how they are declared. Are they just named tuples? Because that really has nothing to do with structs at all. Same with newtype'd structs, I fear. It all feels very haphazard. If nothing else, we really need some better docs here.

@mzabaluev
Copy link
Contributor

As things stand, type does not fully work as an alias due to e.g. #5635.
What's even more curious, a type made out of an instantiated generic like A<int> does not work in expressions where A<int> would result in syntax fail and must instead be written A::<int>. Does it mean that type works on syntactic level?

@graydon
Copy link
Contributor

graydon commented May 22, 2013

nominating for backwards compat. if we're going to do this, we need to decide to do it. if not, close.

@graydon
Copy link
Contributor

graydon commented May 22, 2013

(Incidentally, I'm not in favour of adding alias, but would be ok with extending use if we could make it work. Otherwise I think it's not a big enough deal to warrant the code-breakage.)

@graydon
Copy link
Contributor

graydon commented May 23, 2013

closing as WONTFIX

@graydon graydon closed this as completed May 23, 2013
flip1995 added a commit to flip1995/rust that referenced this issue Jul 14, 2020
Move range_minus_one to pedantic

This moves the range_minus_one lint to the pedantic category, so there
will not be any warnings emitted by default. This should work around
problems where the suggestion is impossible to resolve due to the range
consumer only accepting a specific range implementation, rather than the
`RangeBounds` trait (see rust-lang#3307).

While it is possible to work around this by extracting the boundary into
a variable, I don't think clippy should encourage people to disable or
work around lints, but instead the lints should be fixable. So hopefully
this will help until a proper implementation checks what the range is
used for.

*Please keep the line below*
changelog: move [`range_minus_one`] to pedantic
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 14, 2020
Rollup of 5 pull requests

Successful merges:

 - rust-lang#5443 (Some accuracy lints for floating point operations)
 - rust-lang#5752 (Move range_minus_one to pedantic)
 - rust-lang#5756 (unnecessary_sort_by: avoid linting if key borrows)
 - rust-lang#5784 (Fix out of bounds access by checking length equality BEFORE accessing by index.)
 - rust-lang#5786 (fix phrase in new_lint issue template)

Failed merges:

r? @ghost

changelog: rollup
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

No branches or pull requests

5 participants