Rename UFCS to accurately reflect its functionality.

[eddyb]

UFCS ("Unified Function Call Syntax" #132) ended up being merely an "unified syntax", but not specific to functions and less so to calls.

It also doesn't allow calling free functions like methods, like D's UFCS does.

To avoid turning our feature into another RAII-AA ("Acronym Accident"), I propose renaming it to AILS ("Associated Item Lookup Syntax").

[bstrie]

Still sounds too jargony, why not just "trait disambiguation syntax".

[eddyb]

@bstrie because it also works for non-trait Associated Items.

[8573]

+1 for replacing “UFCS”.

[bstrie]

Acronyms are a barrier to comprehension, I'm not a fan of inventing new ones. "UFCS" only works because it's vaguely familiar from other languages (though we do it exactly opposite to other languages, so I wouldn't be sad to see it go). Let's come up with a name that isn't so verbose that it warrants an acronym. Just "lookup syntax" would probably suffice.

[eddyb]

@bstrie but do you mean Module Lookup Syntax, Field/Method Lookup Syntax or Associated Item Lookup Syntax?
I wouldn't mind using Associated Lookup Syntax without an acronym, but ALS already means something, so it might end up a bit awkward.
It could also get confusing at times, and may lead to questions like "what's it associated with?".

[Kimundi]

@bstrie: "lookup syntax" is a very vague term though, and "UFCS" is currently being used. So, assuming that people will continue to use a more specific term, I'd rather it be AILS than UFCS.

[bstrie]

Acronyms are opaque and only raise the barrier of entry to learning. That aside, "AILS" sounds like a disease and is approximately as disquieting as our unfortunate abbreviation of "std" for the standard library. It's not worth the effort to go from one slightly-incorrect-and-slightly-known acronym to a techically-correct-but-entirely-unknown acronym. I'm not a fan of "UFCS", but "AILS" isn't better by any stretch of the imagination. I'm sure you can come up with a description that's both pithy and self-explanatory.

[eddyb]

cc @steveklabnik @aturon

[Havvy]

I consider "Associated Item Lookup Syntax" to be self-explanatory as long as you know what an associated item is.

[bstrie]

"Item" is already jargon, and "associated item" is doubly so. Don't make the same mistake as the Unicode consortium and presume that the technical precision of a phrase like "grapheme cluster" will either aid in understanding or actually make anybody want to use said phrase.

Let's also step back and realize that the designers of C++ must have thought they were onto something when they coined "RAII" and "SFINAE". Naming is hard, acronyms are the lazy way out.

[nham]

I agree with @bstrie that confusing acronyms should not be used in the documentation. However, I'm not sure I agree that "associated item" is too jargony. Calling it "the associated item lookup syntax" seems like it might work. If you want to use the "AILS" acronym in a conversation where you're reasonably sure no one will be confused by it, then that seems okay to me.

[aturon]

cc @nikomatsakis

How about:

• foo::bar::baz is a "path", whose components can have different kinds, including modules, types, traits, functions, etc.
• <T as Trait> is a "disambiguator"

[eddyb]

@aturon we also call <T as Trait> "qualified" (path/syntax).

The feature to be named (previously "UFCS") encompasses the use of 3 different path syntaxes:

• <X as Trait>::Y "fully qualified (by type and trait) path"
• <X>::Y "(type-)qualified path"
• X::Y "(plain) path"

With the last one being usable as both Trait::X and Type::X where the latter is a shorthand for <Type>::X, and associated path components can be chained, e.g. module::Type::AssocTyA::AssocTyB::AssocTyC::method is valid (but perhaps not fully implemented).

Without this feature, Type::trait_method wouldn't work, so it's not enough to call it "Path Disambiguation Syntax" or "Qualified Path Syntax", a name should encompass both qualified and unqualified forms.

[aturon]

@eddyb Right, so I know that various aspects of paths were added under the moniker of UFCS, but I'm wondering whether we actually need to keep around a name for those feature "deltas" at all, rather than just straightforward names for the different kinds of paths component as you suggest.

[eddyb]

@aturon as long as we stop using "UFCS" as a descriptor for all possible path combinations, I personally don't mind it. I'm curious what @bstrie thinks of it.

[withoutboats]

This was linked from the meeting minutes, in which OIBITs were mentioned as another example - I don't know if this comment is off-topic. OIBIT is really bad terminology, since the traits its referring to (Send and Sync) are neither opt-in nor built-in at this point (well they have a special status for evaluating trait objects, but that'll probably go too). I've been referring to the concept as "traits with default impls," which is accurate but not at all catchy.

I've never needed the term UFCS to think or talk about Rust syntax; I started using Rust in December, so I don't think I experienced Rust without it. I'm not sure a name for it is actually useful and thinking of it as a distinct thing from "Rust syntax" might be unnecessary.

[withoutboats]

Is there a term that we're using now or do people still say UFCS?

When I need to refer to the fully disambiguated name for an item, I usually call it the "canonical name" or "disambiguous name." I don't usually refer to the syntax for such names in itself.

[strega-nil]

@withoutboats I think UFCS is still the accepted term.

[steveklabnik]

Almost exactly a year ago, we had a long discussion in @rust-lang/core about this. I never sent in a PR.

I think it was something like "path disambiguation syntax", cc @eddyb as well as core

[strega-nil]

@steveklabnik It may be that that was what you chose, but the accepted wording of the community is UFCS.

IMO, we need to come up with a term that rolls off the tongue better than "path disambiguation syntax", if we actually want to replace UFCS; "RAII" is not accepted in the C++ community because it explains what's happening well, it's used because it's easy to say, and embedded in the mindspace of community members.

[withoutboats]

As I've said, I don't find myself needing to discuss this syntactic form often. While an acronym like UFCS was useful when designing and implementing this aspect of the language, I don't think this needs to be named as such.

I'd prefer if rather than treating this as a discrete 'feature,' in documentation & discussion we just regard all items as having a "fully disambiguated" or "canonical" name, for which this is the syntax (therefore the "disambiguous'"or "canonical" syntax). Probably we should document that this syntax is sometimes called UFCS for historical reasons, but I don't think it should be conceived of in the manner that the terminology of UFCS has suggested.

This is similar to how if/when the ATC proposal is implemented, I believe we should just document it as a part of documenting associated types - as 'associated types can take parameters' - rather than framing it as a distinct feature.

[strega-nil]

@withoutboats People talk about it on IRC, however, like, "how do I call this" "oh, use UFCS"; or "how do I access a specific type parameter", "use UFCS".

[Ericson2314]

Very much in agreement with @withoutboats's and @eddyb's sentiment here. I think not-neccesarily-cannoncial paths that nevertheless include various associated items could be called "dotless"—there's a lot of catchiness in that adjective if I may say so :).

[aturon]

@withoutboats

I'd prefer if rather than treating this as a discrete 'feature,' in documentation & discussion we just regard all items as having a "fully disambiguated" or "canonical" name, for which this is the syntax (therefore the "disambiguous'"or "canonical" syntax).

I basically agree with this -- note that what's disambiguated is not just the name, but also the borrowing and dereferencing being performed on self.

[aturon]

@withoutboats How about "explicit syntax"?

[eddyb]

"explicit path" is a more specific term I could get behind.

[aturon]

@withoutboats Thinking a bit more: I'm not sure you can avoid it being thought of as a discrete feature, given that it has discrete syntax, and that we do need some way to refer to that syntax. I don't think that "UFCS" as such refers to a particularly coherent feature, though.

I want to be able to say something like: "When you invoke a method using XX syntax, self is no longer borrowed automatically".

[strega-nil]

@aturon @eddyb I think it needs to be a little snappier and also shorter to type. Both "explicit path" and "explicit syntax" are hard to type, and hard to say, and I'd personally rather just use UFCS than those (which means that a lot of other people will also).

[aturon]

@ubsan That's going to be a hard bar to meet. I'll note that we have terms like "associated types", which are much longer yet come up much more often.

[arielb1]

I suppose that a part of the confusion is that <Foo as Clone>::clone(foo) aka "UFCS" is not an atomic syntax, but rather a free function call whose callee is what I call an [explicit] associated item projection (or more specifically, [explicit] method projection).

Therefore,

When you invoke a method using XX syntax, self is no longer borrowed automatically

Should probably be

When you invoke a method using [free] function call syntax, self is no longer borrowed automatically

I suppose I wouldn't call Vec::push a projection but rather an [explicit] method path, so probably "when autoderef is confusing you, try using a free function call".

[Centril]

This issue seems out of place here; I've refiled to the reference.