-
Notifications
You must be signed in to change notification settings - Fork 1.6k
unified function call syntax #4
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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.