Class helpers (was: Small contribution to readability (of at least my code))

[John Yates]

I am posting this as a new thread because I do not want to undermine the ongoing discussion of what I will term the "namespace class" proposal.

Assuming that proposal is successful I see opportunity to address another C++ rough edge.  As in the former proposal this adds no actual new functionality to C++ but it would make it more pleasant to use.  (In some respects this is a less ambitious, less complex attack on the usage sweet spot that the various Uniform Call Syntax proposals seem to address.)

A tension I have encountered repeatedly (and resolve differently on different occasions) is the requirement to make a function a class member in-order to confer upon it method invocation syntax.

When I implement an abstraction I start with a base set of methods that can only be implemented as true class members (i.e. they require access to the class' internals).  Often after that I have an additional set of services, wrappers, what-have-you that I want to present as part of how a client should think about the class even though they all can be implemented entirely in terms my earlier base methods.  Ideally I want my users to use method invocation syntax to call operations in this second set.  And indeed I can achieve that by including those operations in the class definition.  Often though that seems a high price to pay merely to achieve syntactic uniformity.

Already today a classic namespace need not be defined all at once.  Disparate sites can open the same namespace in order to add entries.  I would like to suggest that "namespace class" have a similar behavior:

• If a "namespace class" function definition has a signature that matches a method within the corresponding class still missing a definition then it "completes" that method.
• Otherwise such a"namespace class" function becomes a member of the namespace class (but not the class).  It must be called using method invocation syntax.  Its implementation can use unqualified naming to refer to public members of the clas.  OTOH it is granted no special access (it is restricted to exploiting the public interface).
• No virtual nor static functions.
• No data (neither static nor instance).

A const method qualifier should be allowed with the obvious semantics.

/john

[Nevin Liber]

On 19 November 2015 at 16:08, John Yates <jo...@yates-sheets.org> wrote:

A tension I have encountered repeatedly (and resolve differently on different occasions) is the requirement to make a function a class member in-order to confer upon it method invocation syntax.

Is there anything in here not covered by the Unified Call Syntax (n4474 and p0131r0) proposal?

Not that you'll necessarily agree with the conclusion, but after debating this at multiple meetings, I believe the direction reached by EWG in Kona is that f(x, ...) can implicitly call x.f(...), but not the other way around.

--

 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  +1-847-691-1404

[Nicol Bolas]

On Thursday, November 19, 2015 at 5:24:25 PM UTC-5, Nevin ":-)" Liber wrote:

On 19 November 2015 at 16:08, John Yates <jo...@yates-sheets.org> wrote:

A tension I have encountered repeatedly (and resolve differently on different occasions) is the requirement to make a function a class member in-order to confer upon it method invocation syntax.

Is there anything in here not covered by the Unified Call Syntax (n4474 and p0131r0) proposal?

Not that you'll necessarily agree with the conclusion, but after debating this at multiple meetings, I believe the direction reached by EWG in Kona is that f(x, ...) can implicitly call x.f(...), but not the other way around.

It should also be noted that the committee struck down exactly what he is asking for, in P0079. That is, the ability to declare that a non-member should be callable as a member of a class.

[Nicol Bolas]

On Thursday, November 19, 2015 at 5:08:31 PM UTC-5, John Yates wrote:

I am posting this as a new thread because I do not want to undermine the ongoing discussion of what I will term the "namespace class" proposal.

Assuming that proposal is successful I see opportunity to address another C++ rough edge.  As in the former proposal this adds no actual new functionality to C++ but it would make it more pleasant to use.

No, inserting functions into a class from outside of the class's definition is very much adding new functionality. It's either directly inserting methods into a class or its changing what `x.f(...)` could call. Either way, it is very much doing something that couldn't be done before.

Ideally I want my users to use method invocation syntax to call operations in this second set. And indeed I can achieve that by including those operations in the class definition.  Often though that seems a high price to pay merely to achieve syntactic uniformity.

Why do you consider making a member function to be "a high price"?
 

Already today a classic namespace need not be defined all at once.  Disparate sites can open the same namespace in order to add entries.  I would like to suggest that "namespace class" have a similar behavior:

Until your little addendum, there was no such thing as a "namespace class". A "namespace class" declaration, as defined in the other thread, is not creating a construct. It is not a namespace that is a class or anything of the kind. It is merely a way to avoid adding repetitive syntax when defining members of a class. The `namespace` keyword is simply being used to tell the compiler that this is not a class definition.

What you want transforms this from being merely syntactic sugar into actually meaning something. Your idea makes a "namespace class" an actual language construct.

• If a "namespace class" function definition has a signature that matches a method within the corresponding class still missing a definition then it "completes" that method.
• Otherwise such a"namespace class" function becomes a member of the namespace class (but not the class).  It must be called using method invocation syntax.  Its implementation can use unqualified naming to refer to public members of the clas.  OTOH it is granted no special access (it is restricted to exploiting the public interface).

OK, so how does that work? Do they have an implicit `this` pointer? Are those functions considered namespace-scoped functions or member functions? If they're member functions, can you get member pointers to them? If not... what does this mean? How do you name these functions? Would you say `X::FuncName`?

Are you allowed to inject constructors into classes? What about special member functions like assignment operators? What about those overloaded operators that have to be declared as members of types; can those too be injected?

Can you declare `using namespace X`, where X is the "namespace class" and have that actually do something? What would it mean? Can you declare an namespace class `inline`?

Maybe you should think the idea through a bit more.

• No virtual nor static functions.
• No data (neither static nor instance).

Why not? I mean, if you can insert functions into a class, why not be able to insert at least static data members?

[John Yates]

On Thu, Nov 19, 2015 at 5:23 PM, Nevin Liber <ne...@eviloverlord.com> wrote:

Is there anything in here not covered by the Unified Call Syntax (n4474 and p0131r0) proposal?

After reading your references more attentively and especially follwoing Nicol's comments I have recast my ideas.  More to follow.

/john