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

Ability to specify self parameter in static method call #8888

Closed
erickt opened this issue Aug 30, 2013 · 19 comments
Closed

Ability to specify self parameter in static method call #8888

erickt opened this issue Aug 30, 2013 · 19 comments
Labels
A-type-system Area: Type system P-medium Medium priority
Milestone

Comments

@erickt
Copy link
Contributor

erickt commented Aug 30, 2013

The commit 8693943 removed the ability for us to do:

trait SizeOf {
     fn size_of() -> uint { sys::size_of::<T>() } 
}

fn size_of<T: SizeOf>() -> uint {
    SizeOf::size_of::<T>()
}

@pcwalton has proposed that we add support for expressing the Self type of a static method with:

fn size_of<T: SizeOf>() -> uint {
    SizeOf::<for T>::size_of()
}

but I've heard that we haven't settled on this syntax yet.

@dwrensha
Copy link
Contributor

+1

@SimonSapin
Copy link
Contributor

Is this related to #6894?

@brson
Copy link
Contributor

brson commented Oct 15, 2013

Nominating

@catamorphism
Copy link
Contributor

1.0, high

@nikomatsakis
Copy link
Contributor

Although I initially proposed this syntax, it sure is ugly. I am still worried we're making a mistake by not supporting 'C++ style'.

@nikomatsakis
Copy link
Contributor

This is also related to the question of whether we want to support multiparameter typeclasses in their full generality.

@SimonSapin
Copy link
Contributor

Shouldn’t this be just T::size_of()?

@pnkfelix
Copy link
Member

@SimonSapin not currently; see #6894

@SimonSapin
Copy link
Contributor

@pnkfelix So, we can’t do T::size_of() yet because it requires a bunch of work, but that’s what we want to do eventually. Do I understand this correctly?

@pnkfelix
Copy link
Member

@SimonSapin yeah, we want to support T::size_of() eventually, or something very close to it.

@pnkfelix
Copy link
Member

I think we want to do this for 1.0. It came up in a recent weekly meeting. Our plan, I think, is to keep supporting the Trait::size_of() invocation form (so its not a backward compatibility risk), but we probably want to add the T::size_of() (with the potential for compile-time error if there is a collision/name-ambiguity) and unambiguous SizeOf::<for T>::size_of() invocation forms for 1.0 as well.

Nominating, presuming that it will get P-high.

@pnkfelix
Copy link
Member

Wait, this is already P-high ...

@pnkfelix
Copy link
Member

Ah, the description didn't cover the T::size_of() case. I'll check if there's another ticket for that.

@pnkfelix
Copy link
Member

The T::size_of() form is in #6894 which was recently nominated.

brendanzab added a commit to brendanzab/rust that referenced this issue Jan 17, 2014
This removes the `Primitive::{bits, bytes, is_signed}` methods and removes the operator trait constraints, for the reasons outlined below:

- The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES` statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should probably be deprecated in the future in favor of using the `std::mem::size_of` function (see rust-lang#11621).

- `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for rust-lang#8888.

- The operator trait constraints are already covered by the `Num` trait.
bors added a commit that referenced this issue Jan 18, 2014
As part of #10387, this removes the `Primitive::{bits, bytes, is_signed}` methods and removes the trait's operator trait constraints for the reasons outlined below:

- The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES`statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should be deprecated in the future in favor of using the `std::mem::size_of` function (see #11621).

- `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for #8888.

- The operator trait constraints are already covered by the `Num` trait.
tweber12 pushed a commit to tweber12/rust that referenced this issue Jan 18, 2014
This removes the `Primitive::{bits, bytes, is_signed}` methods and removes the operator trait constraints, for the reasons outlined below:

- The `Primitive::{bits, bytes}` associated functions were originally added to reflect the existing `BITS` and `BYTES` statics included in the numeric modules. These statics are only exist as a workaround for Rust's lack of CTFE, and should probably be deprecated in the future in favor of using the `std::mem::size_of` function (see rust-lang#11621).

- `Primitive::is_signed` seems to be of little utility and does not seem to be used anywhere in the Rust compiler or libraries. It is also rather ugly to call due to the `Option<Self>` workaround for rust-lang#8888.

- The operator trait constraints are already covered by the `Num` trait.
@nrc
Copy link
Member

nrc commented Feb 18, 2014

working on this

@brson
Copy link
Contributor

brson commented Aug 1, 2014

@nick29581 Do you know what the state of this is? I feel like I haven't heard much about it. Does UFCS solve it?

@nrc
Copy link
Member

nrc commented Aug 4, 2014

@brson Yes, UFCS should solve this. I'm not sure who is implementing now.

@aturon
Copy link
Member

aturon commented Sep 11, 2014

Note that UFCS is not considered 1.0 blocking, but this issue is.

Nominating: we need to decide whether this functionality blocks 1.0 or not. (Also, this ticket can likely be closed as a dup of #16293).

@pnkfelix
Copy link
Member

Would reassign as P-high, not on 1.0 milestone.

But really, just closing as dupe of #16293.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system P-medium Medium priority
Projects
None yet
Development

No branches or pull requests

9 participants