Uniform function call syntax

int first(int[] arr)

{

return arr[0];

}

int[] addone(int[] arr)

{

int[] result;

foreach (value; arr) {

result ~= value + 1;

}

return result;

}

void main()

{

auto a = [0, 1, 2, 3];

// all the following are correct and equivalent

int b = first(a);

int c = a.first;

// chaining

int[] e = a.addone().addone();

}

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)

# all the following are correct

v3 = add(v1, v2)

v4 = v1.add(v2)

v5 = v1.add(v2).add(v4)

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.{{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}}

In 2016 it was proposed a second time for addition to C++ by Bjarne Stroustrup{{cite web |title=UFCS proposal |url=http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf |website=Open-std.org |accessdate=1 October 2017}} and Herb Sutter, to reduce the ambiguous decision between writing free functions and member functions, to simplify the writing of 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 functions);{{cite web |title=Using IntelliSense |url=https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx |website=MSDN |accessdate=1 October 2017}} however, this leads to excessive coupling between classes.{{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}} This was again, in 2023, proposed by Herb Sutter{{Cite web |last=Sutter |first=Herb |date=13 October 2023 |title=Unified function call syntax (UFCS) |url=https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p3021r0.pdf }} claiming new information and insights, as well as an experimental implementation in the cppfront compiler.

Until 2018, it was common{{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}} 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 is 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. Member functions can also be used as free functions through a qualified (namespaced) path. The term UFCS is incorrect for these uses, as it allows using methods as (namespaced) free functions, but not using free functions as methods.

• Trait (computer programming)
• Interface (computer programming)
• Go (programming language), another language with a more open philosophy to methods
• Loose coupling
• Duck typing
• Method chaining

{{Reflist}}

Category:Articles with example code

Category:Articles with example D code

Category:Object-oriented programming

Category:Subroutines