Extension methods

81 views
Skip to first unread message

Sidney Congard

unread,
Mar 17, 2018, 7:27:10 PM3/17/18
to ISO C++ Standard - Future Proposals

Hello, I would like to know if the extension methods proposal (such as presented in this paper :
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0079r0.pdf) is considered for C++20.

This proposal allows to define free functions available with the member function syntax, for existing
classes :

struct int_array {
    int* data
;
    int size
;
};

// 'this' makes back an extension method
// Usage : myArray.back()
int&
back(int_array array* this) {
   
return *(array.data + size - 1);
}

I think there is great benefits to implement functions as not member ones :
    We get a better encapsulation because less functions can act on the private object's state
    We can add behavior to existing classes and (optionnally constrained) template classes without
    modifying them
But when it comes to using the function, I prefer the member function syntax :
    It is easier to read (well, for me)
    It permit proper chaining of function calls (a.f1().f2() rather than f2(f1(a)))
    Is what is currently widely adopted to act on an object, at the point where the same functions
    are copyied to be added to similar classes
    It is more friendly to use with a development environment proposing which member functions are
    available for the current object

Moreover, with concepts surely incoming with C++20,
(https://www.reddit.com/r/cpp/comments/854mu9/2018_jacksonville_iso_c_committee_reddit_trip/)
we could define extension methods for concepts.

A well-known exemple is LINQ in C# : it is available for every class which implement IEnumerable
(an equivalent of C++ iterable containers, with begin() and end()).

Here is a little exemple in C#, where 'Where' and 'Take' functions are extension methods.

var meal = EnumerateFridge()
   
.Where(food => food.HasChocolate())
   
.Take(7);

Nicolas Lesser

unread,
Mar 17, 2018, 8:01:54 PM3/17/18
to std-pr...@isocpp.org
They proposal is from 2015, where it was rejected in Kona from EWG. Here are some concerns that were mentioned:

- C# people don't like this
- If a class adds a new function which happens to be the same as your extension function, you're going to be surprised
- It's not uniform, basically just syntactic sugar some of the time


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/097834ee-5d25-484f-8641-b64707bd53a7%40isocpp.org.

Sidney Congard

unread,
Mar 17, 2018, 8:14:18 PM3/17/18
to ISO C++ Standard - Future Proposals

Thank you !

It's a little sad though, regarding the cost paid by some code to emulate this

Gašper Ažman

unread,
Mar 17, 2018, 8:27:47 PM3/17/18
to std-pr...@isocpp.org
Look at p0847 - we are going there, just not yet.

G

On Sun, Mar 18, 2018, 00:14 Sidney Congard <sidney....@gmail.com> wrote:

Thank you !

It's a little sad though, regarding the cost paid by some code to emulate this

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.

Sidney Congard

unread,
Mar 17, 2018, 8:54:48 PM3/17/18
to ISO C++ Standard - Future Proposals

Le samedi 17 mars 2018 20:27:47 UTC-4, Gašper Ažman a écrit :
Look at p0847 - we are going there, just not yet.

G

I didn't see that coming ; by this, I meant the extension method ...
But thanks for your comment, I didn't know about this (nice) proposal !
Reply all
Reply to author
Forward
0 new messages