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

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-typesystem Area: The type system P-medium Medium priority
Milestone
1.0

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?

@SimonSapin SimonSapin mentioned this issue Sep 3, 2013
Closed
@pnkfelix pnkfelix mentioned this issue Sep 4, 2013
Closed
@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.

@brendanzab brendanzab mentioned this issue Nov 9, 2013
Closed
brendanzab added a commit to brendanzab/rust that referenced this issue Nov 9, 2013
@brendanzab
Add FIXME comments referencing rust-lang#6894 and rust-lang#8888
e461664
@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 brendanzab mentioned this issue Jan 17, 2014
Closed
brendanzab added a commit to brendanzab/rust that referenced this issue Jan 17, 2014
@brendanzab
Simplify std::num::Primitive trait definition
472dfe7 
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
@bors
auto merge of #11622 : bjz/rust/simplify-primitive-trait, r=brson
2952685 
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
@brendanzab @tweber12
Simplify std::num::Primitive trait definition
b7614b7 
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 nrc mentioned this issue Feb 18, 2014
Closed
@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.

@alexchandel alexchandel mentioned this issue Dec 18, 2014
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-typesystem Area: The type system P-medium Medium priority
Projects
None yet
Milestone
1.0
Development

No branches or pull requests
9 participants
@erickt @brson @nikomatsakis @pnkfelix @SimonSapin @catamorphism @dwrensha @aturon @nrc