-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
unified function call syntax #4
Conversation
``` | ||
fn f<G: Graph>(n1: (G:Graph)::Node, n2: G::Node) { // n1 and n2 have the same type | ||
... | ||
let x = G::Node::magic_number; // associated value |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The full syntax for this is written as (G: Graph)::Node::magic_number
, right?
I'm still mildly concerned about this from a grammar perspective, especially if we ever use :
for type ascription on expressions (because then in (x: y...
, x
can legitimately be either a type or an expression).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is any particular ambiguity so long as we restrict the set of type expressions to paths. Though this is perhaps an unfortunate limitation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even with just paths, it means that something like (Foo<T>: Graph)
can't work (unless we use Foo::<T>
there too).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, you would write Foo::<T>
if this appears in an expression context.
As a side note, could you format this to a line width of 80 characters? |
Does this proposal exclude |
@ben0x539 All those should work, the components of a path should be allowed to be types, not just trait or struct names |
I thought it disallowed things like |
Does this cover the idea that: trait A {
fn a(&self) -> Self;
} Is just sugar for: trait A {
fn a(self: &Self) -> Self;
} ? |
@bjz I think that comes out of my (not yet published) RFC on traits. I need to get to work on finishing that. |
From reading the proposal, it wasn't clear to me how this case would be handled: trait T
{
fn method(&self) {}
}
struct A;
impl A
{
fn method(&self) {}
}
impl T for A {}
fn main()
{
let a = A;
(A: T)::method(a); // easy to call the trait's method
A::method(a); // but how to call the inherent method?
} |
@SiegeLord This is a little bit orthogonal, since it is about calling overridden vs overriding methods rather than specifying a method in one trait from a set of traits.
|
Closed in favour of #132 |
Explicitly point out alternatives to `trait Alias = where PREDICATES;`
Associated type bounds: clarify stuff...
Document more Community Team goals
Type deduction RFC
Expand on the guide-level explanation
Add RFC summary translations
No description provided.