Implicit pointer dereference on member access

[romangg]

Dependency injection is a widely used pattern that I try to use whenever possible in C++ instead of globals. Another pattern is composition and I usually divide larger classes into smaller ones that are composited into each other. Both patterns allow duck typing in a sense that you can do something like a.b.c.f().

But in C++ this is not uniformly doable for dependencies that are reference types due to pointers having -> syntax and C++ references being problematic as members of a class.

Would it be doable and a good idea to allow in cppfront the same syntax for accessing the fields and methods in a (dependency as) pointer like these of a (composited) value type? This would simplify the language and ease the usage of dependency injection.

Here a small cppfront code example of what I mean (see last line in main where dereferencing is necessary):

dependency : type = {
    print: (this) = {
        std::cout << "print from dependency\n";
    }
}

composite : type = {
    // Without int parameter doesn't compile for some reason...
    operator=: (out this, _: int) = {
    }
    print: (this) = {
        std::cout << "print from composite\n";
    }
}

my_class : type = {
    operator=: (out this, d: *dependency) = {
        dep = d;
    }

    print: (this) = {
        std::cout << "print from my_class\n";
    }

    public dep: *dependency;
    public cmp: composite = (1);
}

main: () = {
    d: dependency = ();
    x: my_class = (d&);
    x.print();
    x.cmp.print();
    x.dep*.print();
    // Instead: x.dep.print()
}

I'm not sure how this should interact with UFCS. Maybe the compiler should check if there is a free function with the same name taking a pointer of the type as first argument and if yes, prefer the free function, or it should error out then because of ambiguity.

[msadeqhe]

How can we access the member pointer itself? For example (UFCS):

print: (dep: *dependency) = {
    std::cout << "Print from a free function.\n";
}

x.dep.print();

[romangg]

Yea, that's something I thought of too. My initial thought was that the compiler should check this or there are some fallback semantics like with UFCS (see wiki).

On the other side looking at your example I just realized how one can have an "implicit" pointer dereference already now with cppfront. By providing a free function like yours that in turn calls the member function:

print: (dep: *dependency) = {
    // UFCS print(dep*) doesn't work here for some reason
    dep*.print();
}

My example above with this in compiler explorer.

Of course if you often access dependencies providing such wrappers could be painful. Maybe the compiler could generate such a function for any member function automatically if there is none. And then explicitly providing such a function is overriding this default behavior.

[romangg]

That would only work for member functions though. If dep has a field y I want to access, then I would still need to do x.dep*.y. 😒

[SebastianTroy]

Would this compiler check you're asking for break the context free compiling? Also I believe references are not going to be in cpp2 anyway, afaik they were mainly added for parameter passing, but cpp2 uses in, out, inout etc On 11 September 2023 00:09:13 Roman Gilg ***@***.***> wrote: Dependency injection is a wildly used pattern that I try to use whenever possible in C++ instead of globals. Another pattern is composition and I usually divide larger classes into smaller ones that are composited into each other. Both patterns allow duck typing in a sense that you can do a.b.c.f(). But in C++ this is not uniformly doable for dependencies that are reference types due to pointers having -> syntax and C++ references being problematic as members of a class. Would it be doable and a good idea to allow in cppfront the same syntax for accessing the fields and methods of (dependencies as) pointers like these of (composited) value types? This would simplify the language and ease the usage of dependency injection. Here a small cppfront code example of what I mean (see last line in main where dereferencing is necessary): dependency : type = { print: (this) = { std::cout << "print from dependency\n"; } } composite : type = { // Without int parameter doesn't compile for some reason... operator=: (out this, _: int) = { } print: (this) = { std::cout << "print from composite\n"; } } my_class : type = { operator=: (out this, d: *dependency) = { dep = d; } print: (this) = { std::cout << "print from my_class\n"; } public dep: *dependency; public cmp: composite = (1); } main: () = { d: dependency = (); x: my_class = (d&); x.print(); x.cmp.print(); x.dep*.print(); // Instead: x.dep.print() } I'm not sure how this should interact with UFCS. Maybe the compiler should check if there is a free function with the same name taking a pointer of the type as first argument and if yes, prefer the free function, or it should error out then because of ambiguity. — Reply to this email directly, view it on GitHub<#671>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQMCL2ZZXEPCBI63YZ3XZZCBPANCNFSM6AAAAAA4SPJJGU>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[romangg]

Would this compiler check you're asking for break the context free compiling?

I'm unsure. There are the UFCS fallback semantics, that sound similar to me. In the wiki context-free compiling is not discussed.

Also I believe references are not going to be in cpp2 anyway, afaik they were mainly added for parameter passing, but cpp2 uses in, out, inout etc

That's right. I'm thinking here primarily about pointers as data member.

[JohelEGP]

Here's the primary meaning of context-free:

Cpp2 strictly avoids this, and never requires sema to guide parsing. When I say "context-free parsing" this is the primary thing I have in mind... the compiler (and the human) can always parse the current piece of code without getting non-local information from elsewhere.
-- Extract from https://github.com/hsutter/cppfront/wiki/Design-note%3A-Unambiguous-parsing.

[AbhinavK00]

Rust has a feature like this where the smart pointers do auto-dereferencing. But it is implemented at a library level and for things like vector, string, smart pointers etc. Similar to how vectors overload the operator [] as a Qol decision, maybe we can have something similar for smart pointers, except there's no operator to overload in that case. My point is, maybe we could try for a library solution instead of a language one.

[romangg]

Has been a time since I wrote some Rust, so I had to look it up. But yea, you're right. Thanks for mentioning it! It's not only for smart pointers though. The auto-dereferencing of the Dot-operator works for any pointer (the safe variant is called reference in Rust), see Rustonomicon 4.2.

This is part of dereference coercion, see Rust book 15.2.

[hsutter]

Thanks, this is a good question.

In general, Cpp2 goes to "explicit is better than implicit." A lot of Cpp2's simplifications come from removing "implicit invisible magic," such as a magic invisible "this" parameter and magic invisible one-default-fits-all compiler-generated SMFs.

This question touches directly on an example I've used as a poster-child motivating example, namely: It's vital to be able to say clearly which object you're talking about. Therefore, in a language with pointers (and aren't they all these days?), it's vital to be able to distinguish the pointer and the pointee.

For example, let's say we have a type G that has a .get() member, and an object ug of type unique_ptr<G>... what should we expect the following code to mean?

ug.get()

With explicit deref, there's a simple and clear distinction between ug.get() and ug*.get()... and I think it is vitally important to make explicit and visible which object an operation is working on.

Note: This is one of the rocks that have foundered proposals for adding operator& and "smart references" to C++. Cpp2 takes the view that references are neither necessary nor desirable as a general language feature, the way they are plumbed throughout today's C++ language... references were initially invented purely for parameter passing, which is subsumed in Cpp2 by in, inout, etc., and one of the big benefits is that Cpp2 has been able to remove references entirely from the language. As a corollary, that approach just eliminates even the motivation to talk about proposing smart references... which is pretty nice IMO.

[romangg]

In general, Cpp2 goes to "explicit is better than implicit."

I agree that this is a sensible guideline in general. But I want to argue that in this specific case providing an (explicit) mechanism like stated above would still be worth considering because it is useful (see more motivation below in separate comment).

I thought a bit about how auto dereferencing can work with something like smart pointers.

Solution 1: Let smart pointers not act like pointers

A call like ug.get() for ug being a smart pointer like above, always performs on the smart pointer, not on the owned pointer. This would mean that smart pointer have different ergonomics than raw pointers. Something not desirable I assume.

Solution 2: Let smart pointers act like pointers and remove collisions

I'm not sure how UFCS works together with namespaces, but providing functions on the smart pointer in a designated namespace like std::memory::get(std::unique_ptr<T>& ug) should allow to add functions acting on the smart pointer and not on the owned object.

On the other side looking at the current unique_ptr API, there are several functions that could collide with the functions with a type G in unique_ptr<G>. I would argue several of these functions are not necessary though. Going through cppreference

• release: Smart pointers are not meant to become dumb. Don't offer this pit fall in general. Alternatively provide library function in designated namespace.
• reset: Can be done by reassignment to {}.
• swap: Provide library function in designated namespace.
• get: Provide library function in designated namespace or define & instead as such (in 99.9% you don't want to get the address of the smart pointer itself, but of the owned object) use ug*&.
• get_deleter: Personally I've never used this, so can't tell how useful it is.
• operator bool: Not needed with ccp2's model of pointer access only when initialized.

What is definitely needed are ctors, dtor and some data field to store at least the raw pointer to the owned object. Looking at Rust's source code it uses the special compiler field 0 for that. cpp2 could use some similar field with underscores.

Alternatively I have one more idea how to generalize all this: If a type overrides the *-operator the only members it may have are value-setting functions (operator=) and a special single field named *.

That sounds first a bit random, but I think it does make sense. Overriding the *-operator is seldomly useful in my experience, having it defined in types with additional other interface functions usually felt wrong to me. Instead restricting its usage this way allows to implement pointer-like types that still allow automatic pointer dereferencing. For example you could create your own custom pointer-like smart pointer like this:

my_smart_pointer_private_data : <T> type = {
    public owned: T*;
}

my_smart_pointer : <T> type = {
    operator=: (out this, ptr: T*) = {
        *.owned = ptr;
    }

    // Add other value-setting functions as needed.

    // Destructor
    operator=: (move this) = {
        delete *.owned;
    }

    // operator-overload
    operator*: (out T) = {
        return *.owned*;
    }
    

    *: my_smart_pointer_private_data<T>;
}

my_class : type = {
    public value: int = 0;
}

main: () = {
    smart: my_smart_pointer<my_class> = {new my_class()};
    smart.value = 1;
    // Goes out of scope again.
}

Now I admit the working with the special *-field is a bit weird, but implementing such a pointer-like type won't be done often with the restrictions defined above. Alternatively one could of course use any other special name that other types won't use for their fields like Rust does with the 0 name. I just like about the * field name that it is directly related to the operator to begin with.

[romangg]

I think I should motivate automatic pointer dereferencing some more.

In the past C++ code was often written with an OO focus. It was "C + classes". When I look at the legacy code of projects I worked on, in open source and industry, this is hardly not to notice. The result was huge classes with deep inheritance hierarchies and a lot of boiler plate code. The typical example for me is Qt in this regard.

In contrast I - and from what I see online many other C++ developers embracing modern programming techniques - favor small structs together with functional and generic programming techniques.

For example this struct from one of my own projects contains the topology data of a window that means data describing the window in context of the overall space structure. It does not do anything else, its purpose is clear, it is composited into a window like this.

Now assume I want to create a library that is consumed by other projects. And assume I provide some struct that comes with few public data fields like the above struct. Is it really important for the consumer if these fields reference other values or are values themselves? I would say that this is an implementation detail. The consumer only wants to access the data, not know about the memory structure behind that.

In the example with the topology data of window why should it make a difference how a consumer access window topology data like we do in this test? These elements should be accessed through client.geo.size().height() and client.topo.central_output.geometry().height() and without having to know what here is a reference and what not.

The bottom line is that it shouldn't matter if this data is referenced or not. External consumers of my types should not have to care about the memory model.

The solution to this is often to have getters and access all data through these. But this is boiler plate and makes classes fat again. The best data structure for me is small having few public fields. And all transformations to this data structure go through generic functions.

Also at the end a somewhat weaker argument, but let's take a look at other programming languages. I can access data in Rust like this a.b.c.d, I can do this in Javascript, in Python. It's common to provide structured data in this dictionary style. The memory structure behind it should be of no relevance for how to access it.

[AbhinavK00]

You should put it like this-
"This unifies the use automatically lifetime managed resources, whether they're on the stack or free store", any user who didn't create the resource shouldn't have to care about that.

[romangg]

I can access data in Rust like this a.b.c.d, I can do this in Javascript, in Python.

Zig is also dereferencing pointers with dot: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/#pointers-and-slices

This article actually complains about the missing ergonomics when you have to use the raw pointers of unsafe Rust that don't support dereferencing in contrast to the safe Rust pointers (references) that do support it.

[AbhinavK00]

This could also be a simple way to discourage use of raw pointers.

[gregmarr]

We don't want to discourage use of raw pointers completely, just owning raw pointers.

[hsutter]

Correct me if I'm wrong, but it sounds like this is really asking for (all) smart pointers to be treated as smart references?

[romangg]

Sorry, I didn't know what "smart references" were and had to look it up first. Via Google, a reddit thread, a cppcon 2018 talk, a Youtube comment and a GitHub repo I finally arrived at the "Operator Dot" proposal (is it always that difficult? 😅). This proposal defines a Smart reference as "a class with an operator.() defined".

Now after having studied the paper I think it's not the same because the idea here with cpp2 would not be to explicitly overload operator.(). Also the smart references look complicated because they need to share characteristics with C++ references, which cpp2 from what I understood isn't supposed to have in the first place.

The smart pointers here should just behave like raw pointers on access. But under the assumption that the implicit pointer dereference is available for raw pointers, they should also feature that. So my spitballed above custom smart pointer implementation would feature dereferencing of the dot-operator not because it has some explicit overload of the operator.(), but because it overloads the *-operator, and by that is supposed to behave like a raw pointer.

[JohelEGP]

You could go the other way around and write a*.b*.c*.f() instead (https://cpp2.godbolt.org/z/YTc8G3s6f):

dependency_or_resource: <T> type == std::conditional_t<
  std::is_pointer_v<T>, T, std::unique_ptr<T>>;
make_injection: <T> (x: T) -> std::unique_ptr<T> = new<T>(x);
make_injection: <T> (x: * T) -> * T = x;
C: @struct type = {
  f: (this) = { }
}
B: @struct type = {
  c: dependency_or_resource<C> = make_injection(C());
}
gb: B = B();
A: @struct <T> type = {
  b: dependency_or_resource<T> = make_injection(gb&);
}
main: () = {
  a := make_injection(A<* B>());
  a*.b*.c*.f();
}

[romangg]

Interesting approach. But this way. composition of value types is only possible by creating the value on the heap (as C in B), right?

And of course it's more verbose to write *. instead of . all the time.

[JohelEGP]

Interesting approach. But this way. composition of value types is only possible by creating the value on the heap (as C in B), right?

No.
See, for example, std::optional, which provides a dereference operator*.
std::optional<T> stores the T within its object.

And of course it's more verbose to write *. instead of . all the time.

Well, OP wants consistency.
They can't get it with just ..
If it's really that important, maybe they can live with an added * per ..

[romangg]

As another modern language example; in Go implicit pointer dereferencing is also a thing: https://go.dev/tour/moretypes/4

To access the field X of a struct when we have the struct pointer p we could write (*p).X. However, that notation is cumbersome, so the language permits us instead to write just p.X, without the explicit dereference.