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

Revised UFCS proposal #132

Merged
merged 2 commits into from
Aug 6, 2014
Merged

Revised UFCS proposal #132

merged 2 commits into from
Aug 6, 2014

Conversation

nikomatsakis
Copy link
Contributor

A proposal to add an unambiguous syntax for referring to methods and other associated items. An adapted version of the original proposal by @nick29581.


currently active: https://github.com/rust-lang/rfcs/blob/master/text/0132-ufcs.md

@nrc nrc mentioned this pull request Jun 22, 2014
@mstewartgallus
Copy link

How does this relate to function pointers and closures? Will we be able to do something like x.map(Trait::method) like Java 8?

@Ericson2314
Copy link
Contributor

Could trait methods be given an extra type parameter corresponding to the type of the implementer when bound as a function?

e.g.

trait Foo {
    fn method<A: Bar>(&self, bob: &Self) -> Box<A>;
}

binds

pseudo-mod Foo {
    fn method<T: Foo, A: Bar>(alice: &T, bob: &T) -> Box<A>
}

Edit: to disambiguate between trait object member and trait method, I supposed one can call it with explicit type/lifetime parameters (<_>, vs <_,_> in this case). If trait object methods cannot be used in a higher order context that should work. But I wouldn't mind this and something different to unambiguously refer to the trait object type itself, the <_,...> trick isn't the most pleasant.

<ToStr>::to_str

In the former, we are selecting the member `to_str` from the trait `ToStr`.
The result is a function whose type is basically to_struivalent to:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo to_struivalent -- you ran :%s/eq/to_str/g?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think he was using Eq for all the examples and switched to ToStr - gave me a little chuckle.

@bill-myers
Copy link

I think the most natural syntax for <T as ToStr>::to_str would be (impl ToStr for T)::to_str, but unfortunately it's longer.

@huonw huonw merged commit c946fd6 into rust-lang:master Aug 6, 2014
withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
The previous implementation would lead to `Future::wait` deadlocking if
`thread::park` was called during a `poll`. Instead let's keep track of
notifications send to ourself, and don't actually call `thread::park` if we get
a notification.

Closes rust-lang#132
@Centril Centril added A-syntax Syntax related proposals & ideas A-resolve Proposals relating to name resolution. labels Nov 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-resolve Proposals relating to name resolution. A-syntax Syntax related proposals & ideas
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants