-
Notifications
You must be signed in to change notification settings - Fork 501
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
Discuss unambiguous function call syntax #45
Conversation
And shrink the undocumented list
src/expressions.md
Outdated
<T as SizeOf>::size_of() | ||
``` | ||
|
||
Refer to [RFC 132] for further details, motivations, and subtleties of syntax. |
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.
Is this temporary? RFC 1636 seems to say that RFCs aren't supposed to be stable documentation.
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.
Hm, I want to keep the link to the RFC. I need more explanation before the link, though. As that RFC says, the reference should be good enough for normal users to learn how to use a feature without referring to the RFC. Thanks for pointing that RFC out; I'd forgotten about it!
Note to self: Needs more and better examples |
src/expressions.md
Outdated
* Auto-`deref` is undesirable; for example, distinguishing between methods on a | ||
smart pointer itself and the pointer's referent. | ||
* Methods which take no arguments and return properties of a type, like | ||
`SizeOf::size_of()` |
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.
What is SizeOf
?
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 took the example from the RFC. It became out-of-date, apparently! I'll correct it.
src/expressions.md
Outdated
* Auto-`deref` is undesirable; for example, distinguishing between methods on a | ||
smart pointer itself and the pointer's referent | ||
* Methods which take no arguments, like `default()`, and return properties of a | ||
type, like `size_of()` |
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.
How could default()
result in an ambiguity?
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.
fn main() {
let a = Default::default();
println!("{:?}", a);
}
You can (must) use a type annotation or UFCS, right?
This seems alright to me, seems like it could be a little more detailed with some of the specifics of the syntax, but I still feel comfortable landing it in its current state. Any else have thoughts? @steveklabnik @GuillaumeGomez @QuietMisdreavus |
Feel the same: could be more detailed. |
It might be worth mentioning the |
@GuillaumeGomez @QuietMisdreavus @frewsxcv I'd love to add more examples and detail, but I'm afraid the RFC itself seems somewhat out-of-date ( If y'all have any examples I could include, I'd appreciate it! I'll see what I can come up with tonight. |
I was just wanting another sentence or two describing the full form, and mentioning that either Edit: Unless there's more to UFCS than |
src/expressions.md
Outdated
Function calls may sometimes result in ambiguities about receiver or referent. | ||
See [UFCS](#unambiguous-function-call-syntax) for how to resolve this. | ||
|
||
### Unambiguous Function Call Syntax (UFCS) |
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.
So, it's been the opinion of the language team for a long time that "UFCS" is a terrible name and shouldn't be used. It's also not exactly a separate feature, it's that the usual way of calling trait methods is sugar for this syntax. As such, I'm not sure the framing of this PR is right, though there is no way for you to have known that, of course.
I am tempted to merge it as such, and then, we'll end up doing another pass later that cleans this up. This is okay with me, but I don't know how you feel about it.
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.
oh that's helpful. with that in mind, maybe I can have a sub-section here instead of the new section I created? I can describe roughly what you said: "UFCS" confuses the issue, and the RFC didn't add a separate feature. It merely generalized some syntax and turned the then-current syntax into sugar for the fully-qualified function-call syntax. FQFC.
iono @steveklabnik, I'll push some updates, and you can tell me what you think.
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.
that sounds good to me
@steveklabnik let me know what you think of the description now |
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.
looks good to me; i think a link might be broken though?
src/expressions.md
Outdated
@@ -220,6 +220,9 @@ exact `self`-type of the left-hand-side is known, or dynamically dispatching if | |||
the left-hand-side expression is an indirect [trait | |||
object](types.html#trait-objects). | |||
|
|||
[UFCS](#unambiguous-function-call-syntax) allows method invocation using |
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.
this link is still wrong, no?
oh yeah. bigly. thx for heads up
…On Mon, May 22, 2017, 09:36 Steve Klabnik ***@***.***> wrote:
***@***.**** commented on this pull request.
looks good to me; i think a link might be broken though?
------------------------------
In src/expressions.md
<#45 (comment)>
:
> @@ -220,6 +220,9 @@ exact `self`-type of the left-hand-side is known, or dynamically dispatching if
the left-hand-side expression is an indirect [trait
object](types.html#trait-objects).
+[UFCS](#unambiguous-function-call-syntax) allows method invocation using
this link is still wrong, no?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#45 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAYouU4N7_6BrJ6mklVfnW8H5MeO39ORks5r8Z1_gaJpZM4M_5Et>
.
|
@steveklabnik @QuietMisdreavus ok, fixed that last link (and rewrote the sentence around it). |
Great, thanks! |
And shrink the undocumented list
CC #9