Content deleted Content added
No edit summary |
Uniform function call syntax was already mentioned |
||
(28 intermediate revisions by 18 users not shown) | |||
Line 1:
{{Short description|Programming language feature}}
'''Uniform
UFCS is particularly useful when function calls are chained<ref name=":0">{{cite web |url=http://ddili.org/ders/d.en/ufcs.html |title=Universal Function Call Syntax (UFCS) |website=Programming in D |accessdate=1 October 2017}}</ref> (behaving similar to [[Pipe (computer science)|pipes]], or the various dedicated [[Operator (computer programming)|operators]] available in [[functional language]]s for passing values through a series of [[Expression (computer science)|expressions]]). It allows free functions to fill a role similar to [[extension method]]s in some other languages. Another benefit of the syntax is related to completion systems in [[Integrated development environment|IDEs]], which use type information to show a list of available functions, dependent on the context. When the programmer starts with an argument, the set of potentially applicable functions is greatly narrowed down,<ref name="auto">{{cite web |title=Unified Call Syntax |url=https://isocpp.org/files/papers/N4165.pdf |website=Isocpp.org |accessdate=1 October 2017}}</ref> aiding [[discoverability]].
== Examples ==▼
<syntaxhighlight lang="Nim">▼
type Vector = tuple[x, y: int]▼
proc add(a, b: Vector): Vector =▼
(a.x + b.x, a.y + b.y)▼
let▼
v1 = (x: -1, y: 4)▼
v2 = (x: 5, y: -2)▼
v3 = add(v1, v2)▼
v4 = v1.add(v2)▼
v5 = v1.add(v2).add(v1)▼
</syntaxhighlight>▼
▲== Examples ==
=== D programming language ===
<syntaxhighlight lang="
int first(int[] arr)
{
Line 41 ⟶ 25:
auto a = [0, 1, 2, 3];
//
int b = first(a);
int c = a.first
//
int[] e = a.addone().addone();
}
</syntaxhighlight>
===
Proposals for a unification of member function and free function calling syntax have been discussed from the early years of C++ standardization. Glassborow (2004) proposed a Uniform Calling Syntax (UCS), allowing specially annotated free functions to be called with member function notation.<ref>{{cite web|title=N1585: Uniform Calling Syntax (Re-opening public interfaces)|author=Francis Glassborow|date=2 May 2004|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1585.pdf|accessdate=17 December 2018}}</ref>▼
▲type Vector = tuple[x, y: int]
It has more recently been proposed (as of 2016) for addition to C++ by [[Bjarne Stroustrup]]<ref>{{cite web|title="UFCS proposal"|url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf|format=PDF|website=Open-std.org|accessdate=1 October 2017}}</ref> and [[Herb Sutter]],<ref name="auto"/> to reduce the ambiguous decision between writing [[free function (c++)|free function]]s and member functions, to simplify the writing of [[generic programming|templated code]]. Many programmers are tempted to write member functions to get the benefits of the member function syntax (e.g. "[[dot-autocomplete]]" to list [[member function]]s);<ref>{{cite web|title=using intellisense|url=https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx|website=Msdn.microsoft.com|accessdate=1 October 2017}}</ref> however, this leads to excessive [[Coupling (computer programming)|coupling]] between [[Class (computer programming)|classes]].<ref>{{cite web|title=How Non-Member Functions improve encapsulation|url=https://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197|website=Drdobbs.com|accessdate=1 October 2017}}</ref>▼
▲proc add(a, b: Vector): Vector =
== Rust usage of the term ==▼
▲ (a.x + b.x, a.y + b.y)
Until 2018 it was common to use this term when actually referring to ''[https://github.com/rust-lang/rfcs/issues/1140#issuecomment-108644620 qualified/explicit path syntax]'' and most commonly the ''[https://doc.rust-lang.org/1.30.0/book/2018-edition/ch19-03-advanced-traits.html?highlight=trait,function,call#fully-qualified-syntax-for-disambiguation-calling-methods-with-the-same-name Fully Qualified Path syntax].'': because it's possible to have several traits defining the same method implemented on the same struct, a mechanism is needed to disambiguate which trait should be used.▼
▲let
▲ v1 = (x: -1, y: 4)
▲ v2 = (x: 5, y: -2)
# all the following are correct
▲ v3 = add(v1, v2)
▲ v4 = v1.add(v2)
▲</syntaxhighlight>
== C++ proposal ==
▲Proposals for a unification of member function and free function calling syntax have been discussed from the early years of [[C++]] standardization. Glassborow (2004) proposed a
▲
▲== Rust usage of the term ==
▲Until 2018, it was common<ref>{{Cite web |title=Rename UFCS to accurately reflect its functionality. · Issue #1140 · rust-lang/rfcs |url=https://github.com/rust-lang/rfcs/issues/1140 |access-date=2024-05-19 |website=GitHub |language=en}}</ref> to use this term when actually referring to ''[https://github.com/rust-lang/rfcs/issues/1140#issuecomment-108644620 qualified/explicit path syntax]'' and most commonly the ''[https://doc.rust-lang.org/1.30.0/book/2018-edition/ch19-03-advanced-traits.html?highlight=trait,function,call#fully-qualified-syntax-for-disambiguation-calling-methods-with-the-same-name
== See also ==
* [[Trait (computer programming)]]
* [[Interface (computer programming)]]
Line 70 ⟶ 66:
* [[Method chaining]]
== References ==
{{Reflist}}
[[Category:Articles with example code]]▼
[[Category:Object-oriented programming]]
▲[[Category:Source code]]
[[Category:Subroutines]]
▲[[Category:Articles with example code]]
|