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.