class pointer sugar

[HKhademian]

if we have a class, like: class A { var x: i64; }
and a variable from it, like: let a: A = ...;.
then we can access x via dot, like: a.x = 5;;

if we make a pointer from that, like: let b: A* = &a;
there is two way to access x,
first via dereference+dot, like: (*b).x
second via syntax sugar, like: b->x

What is the downside of implicit dereferencing in this scope? like: b.x
Why can't the compiler automatically detect <ptrOfX>.<fieldOfX> and treat it like a normal <objOfX>.<fieldOfX>?

Is there any benefits in explicit dereferencing ?
There is a good youtube video from Tsoding, showing how easy it is to add this feature to TinyC, and how convenience it is to program without -> torture.

[HKhademian]

here is a simple example (inspired by that video):

You start programming for your new side project to forget about 100 previous.
it's a simple game and you want to keep track of a mine field:

class MineField {
  var width: u64;
  var height: u64;
}

then you create a function to calculate area of that field:

fn calculateMineArea(mf: MineField) -> u64 {
  // imaging there is many of mf.X usage
  return mf.width * mf.height;
}

after long programming session, you see you need a huge additional data to keep in MineField, so:

class MineField {
  var width: u64;
  var height: u64;
  var newLargeDate1: u256;
  var newLargeDate2: u256;
  var newLargeDate3: u256;
  var newLargeDate4: u256;
}

So it's obvious to you that, now it's inefficient to copy whole object to just calculate the area, you decide to use pointer instead:

fn calculateMineArea(mf: MineField*) -> u64 {
  // ...
}

Now you realize that you need to replace all those <obj> . <field> with <ptr> -> <field>.

Another similar situation is you need to convert a pointer-arg to a value-arg (for example for better performance - no pointers , ...), now you need to convert all <ptr> -> <field> to <obj> . <field>

Imagine in a large code bases, with many functions to convert, how it's inefficient this process.
and how many lines of code that need to changed (reviewed, examined, approved), just to simply convert a normal value argument to pointer one.

[YagaoDirac]

Emmm, you perfectly explained how to use -> in c++ but I guess this discussion is not about how to use -> in c++. It's about can we replace the -> with . in some/all cases.
I also commented below. I think it's practical in some cases.

[jwtowner]

I'm thinking I agree with this. Hasn't the general trend in C++ been towards value types and hiding pointers (and smart pointers) as implementation details, especially in Boost and the Standard library? The concept-model idiom has been around for over a decade and more recently the C++ metaclasses proposal was introduced to allow for the autogeneration of polymorphic type-erased facades, with pointer semantics and lifetime details abstracted away (similar to Rust's dyn keyword).

Maybe I misunderstand, but the trajectory that C++ is taking seems to be odds with Carbon's choice of syntax here. From reading the available documentation and proposals for Carbon, it looks like there are plans to enable type erasure, metaprogramming and generation of type-erased facets from archetypes. But is there still a way that Carbon can allow for implicit pointer semantics with . syntax, as is done in C++ with l-value references? If not, how are things going to look when interoperating with C++ components that use the concept-model idiom. Using -> syntax almost seems like step backwards for Carbon, although I definitely understand the desire to try to simplify the choice of references vs pointers.

[YagaoDirac]

I think the trend is not hiding pointers. A lot design is to provide more flexibility and allow less code and safer code.
Pointers work differently in different case. Some are basically another way to implement the reference.
Only when pointers are used to handle job inside containers and heavy low-level calculation, the arithmetic of pointers is meaningful. And this is also the dangerous case.
When the containers are implemented well enough, people only need to manipulate them from outside, only the ref-like pointers are needed. This is probably the reason you find more pointers are hidden.
As long as Carbon needs high performance and heavily customized containers, pointer is probably the only choice.

[geoffromer]

I agree that there's a real problem here, but I'm not sure if this sort of auto-dereferencing is a viable way of solving it. The problem is that Carbon, like C++, will probably have a lot of smart pointer types like unique_ptr, and in fact we even expect the "plain" pointer type to actually be a class type (because all types will be library types). So if we allow auto-dereferencing, then a syntax like p.foo has several possible meanings: it could mean p.foo, or (*p).foo, or (**p).foo, etc.

Of course, we could come up with rules for disambiguating among those expressions, but there would still be a risk that the meaning the author intended (or the meaning the reader understands) is different from the meaning that the disambiguation rules choose, leading to unpleasant surprises (anecdotally, I've heard that this can happen in Rust). It also creates problems for software evolution, because it means that adding a method foo to a pointer type always risks breaking client code, even at run time, by changing the meaning of p.foo in client code.

[L4stR1t3s]

If the programmer does not know what the operators do on the type, then s/he probably shouldn't use it?

That's the whole point, you always know what the . operator does in C++: access the members of the object. It never does anything else.
If you make the behaviour of the . operator dependent on arbitrary (yes, arbitrary because anyone can assign automated dereferencing to anything for whatever reason) properties than it becomes so much more complicated to write the simplest code.
a.get();
Does this access the class of a? Does this access something else? What if the something else itself has automated dereferencing? Where do I eventually wind up before get() is called? It's a nightmare to even consider having to program this way.

[OlaFosheimGrostad]

a.get(); Does this access the class of a? Does this access something else? What if the something else itself has automated dereferencing? Where do I eventually wind up before get() is called? It's a nightmare to even consider having to program this way.

Automatic dereferencing only happens on the first level, it will not happen if the object already has been dereferenced.

[geoffromer]

@OlaFosheimGrostad Oh, OK, I think I understand why there's no ambiguity with your approach, but I'm also not very clear on what is gained with that approach, other than saving one keystroke in the common case.

[OlaFosheimGrostad]

@geoffromer Well, there seems to be a demand for more coherent visual syntax for field access, and since the approach of Rust and D leads to names in the pointer shading names in the object I felt that I could come up with something a bit more principled. Anyway, it was an interesting exercise. ;)

If you want to do this only for Carbon, then I would instead suggest that you consider doing all interaction with the smart-pointer through free functions instead of members. E.g. release(smart_pointer) instead of smart_pointer.release(). *shrugs*

[L4stR1t3s]

The original reasons for the existence of -> don't even exist anymore. But it has since morphed into something completely different. I think the most important difference between . and -> in C++ is the fact that the -> operator can be overriden and the . operator can not. Which brings us to smart pointers, that override the -> operator. This means that there is no syntactic difference between accessing a pointer and a smart pointer implementation:

X* x = new X;
x->func();

and

ptr<X> x(new X);
x->func();

This means that if you change from a regular pointer to a smart pointer or vice versa, no other code changes are required. Overriding the . operator sounds like it will be more trouble than its worth. You know what . does, and you also know that -> could be overridden. If only . operator exists and can be overridden, you can't trust anything you do with an object without checking if it overrides . operator. Not to mention the fallout if someone adds a . operator override in the future to an existing object.
This also brings us to a case where you need both -> and . operators in C++:

class X
{
    ...
   int get() { ... }
    ...
}

and

template <class T>
class ptr
{
    ...
    T* get() { ... };
    ...
}

Both the smart ptr template and X have a member function get. So does the following code access the get of X or ptr if you only have the . operator?

ptr<X> x(new X);
auto y = x.get();

You could say that you need to dereference the object to make a distinction:

x.get(); // ptr<X>.get
(*x).get() // X.get()

But this leads to pretty ugly code in some case:
(*(*x).y).z
instead of
x->y->z
And then you can also never allow x.func() for accessing X.func(). Because if someone adds func() to ptr<> in the future you suddenly get completely different behaviour.
So I think there is a reason to have both -> and . operators.

[YagaoDirac]

Probably is because operator-> does concatenation while "." does plain offset.
//c++ code
class A{ int b;}
class C{
A* d;
A* operator->(){return d;}
}
int main(){
A obj_A{};
C obj_C{};
obj_C.d = &obj_A;
obj_C->b; // the -> first finds the d and because d is also a pointer, the -> search inside it for the field of b.
If the example is wrong, ok, I'm not pretty sure about this. I don't write container libraries so, maybe I messed up.
But the dot operator works like:
obj_C.d->b; // dot first finds d and then d is a pointer, so we need a -> to find b.
But if we don't need the cascade, then -> is not needed.

For the cases with only 1 layer, dot and -> result the same. If you prefer dot than ->, it's possible to replace it in such case. But with more layers, -> is still a thing.

My personally prefer ".." rather than ->. Double dots and the classic single dot are similar and easier to type. Readability should not be an issue. The only trouble is that, when a->->b, double dots works like, a....b, probably a space is needed in the mid, like, a.. ..b. But since we can encourage people NOT to do this, just like very very rarely we see any ->-> in c++.

Short version:
-> does concatenation.
If there is only 1 layer, they are the same. Maybe we can replace -> with . in this case.
But when concatenation is needed, -> is still good enough.
c++:
a.b->c; // OK
if a.operator->() returns b, then
a->c; // OK, concatenation.
This example has 2 layers.