5 ms·

This feels analogous to hiding in C++. In C++ by default member functions in a base class don't overload with member functions of the same name in a derived cla

This feels analogous to hiding in C++. In C++ by default member functions in a base class don't overload with member functions of the same name in a derived class. They get hidden.

quietbritishjim 3y ago
Not disagreeing with you but what's interesting is that C++ doesn't hide in this particular situation. Smart pointers implement operator-> and operator* but then ptr.foo() is still always the foo() method of the pointer type (and won't compile if it doesn't have it) - you need ptr->foo() or (*ptr).foo() to get the method of the pointed-to type. It's one of the few places that C++ is more explicit than Rust. I wonder if there's a reason Rust went a different way? I'm mainly a C++ programmer so I'm genuinely curious.
- OskarS 3y ago
  I've always liked that feature of C and C++. There's a lot of people that really hate it and in new languages they unify it to be just a dot. Zig does this as well, for instance. I always liked that the distinction was very explicit: use a.b() if you're calling b() on the object itself, use a->b() if you're de-referencing a first. There are lots of things wrong with C and C++ that Zig and Rust fixes, but I never thought of this one being problematic in any way. It's as easy to type, the difference is obvious, and it's easy to see from a glance what's going on.
  - DixieDev 3y ago
    I'm mostly indifferent to it because it doesn't really harm readability, and it's not hard to know when to use it, but I can seem why it might be more strongly disliked. You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement. It's also annoying if you find that you can refactor `func(T*)` to `func(T&)` and now you have to replace all `->`s with `.`s.
    - codeflo 3y ago
      > You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement. To the extent that this is a problem, it's a problem with references as a language feature in general, not with the arrow syntax.
    - quietbritishjim 3y ago
      > You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement. That's true but I think the bigger motivation is avoiding ambiguity than seeing when an indirection is happening. (You also can't see whether a method is virtual, i.e. indirecting via the vtable, from the call site.) In C++ references don't have any standalone methods or operators so there's no ambiguity from using methods via a reference just using a dot.
  - codeflo 3y ago
    I'm among the people who would have liked to eliminate even this special case and have a convenient postfix derefence for this. So instead of a->b() you'd have a*.b(), and if you need to dereference again, write a**.b() and so on. But as you said, lots of people really seem to hate this kind of thing. Zig is almost there with its dereference syntax, but still kept the magic dereferencing dot.
    - mananaysiempre 3y ago
      Object Pascal strikes again: if a: ^record ... end is a pointer to a record, then a^ is the pointed-to record as a value and a^.b is the way you access a field of it. Incidentally, the authors of Go were asked why they didn’t use a postfix dereference when Sethi noted[1] back in 1981 that C syntax would have been simpler that way, was quoted in Ritchie’s 1993 retrospective[2] on that point, and even their own blog post on declaration syntax pointed out that possibility[3], but IIRC the answer amounted to “but then we wouldn’t have gotten those sweet, sweet C-bandwagon popularity points”. (I also cannot help calling out “Language X” here: One nice approach that nevertheless basically forces implicit dereferencing is that of Algon-68, where all values are constant values; the way to declare a mutable variable is to declare a pointer—a constant value—to a mutable cell; and the way to make the whole thing bearable is to have the compiler infer the minimum possible amount of dereferencing in an expression from the types of the values involved. Then of course it becomes impossible to infer the types, so the ML family goes with the inconvenient dereferencing, and you end up not really using a lot of mutability in ML.) [1] https://dx.doi.org/10.1002/spe.4380110606 https://dx.doi.org/10.1002/spe.4380110606 [2] https://dx.doi.org/10.1145/154766.155580 https://dx.doi.org/10.1145/154766.155580 [3] https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax
  - mr_00ff00 3y ago
    I have limited Zig experience, but actually zig is different from rust or go in this regard, correct? Rust and Go have the pointer have the unified syntax, but I thought in zig it does differentiate between the pointer itself and the value it points to. Rust and Go: ptr.method_on_ptr() ptr.method_from_underlying_val() Zig: ptr.method_on_ptr() ptr.*.method_from_underlying_val()
- gpderetta 3y ago
  People have been trying to get 'operator.' overloading in C++ for the last 20 years. Unfortunately this confusion between pointer operations and pointee operations has always been an obstacle :(.
- mostlylurks 3y ago
  One of the downsides of the C++ approach is that it makes it more cumbersome to make changes in your code. If you for instance make a trivial change where you change a variable from a stack-allocated object accessed directly via .foo() into a heap-allocated one accessed via ->foo(), you have to either manually change all .foo()s into ->foo()s or do some sort of weird work-around, such as making a separate variable that's a reference to the heap allocated object so that you can keep using those .foo()s. This is all relatively pointless busywork, which also pollutes the commit history with relatively meaningless changes.
  - lionkor 3y ago
    those changes in access are semantically different, so i prefer being forced to change code when semantics change
    - Guvante 3y ago
      There is no sematic difference between passing in a reference and passing in a copy of a smart pointers though. Yes there is a difference at the call site between taking a reference to an owned thing and taking potential ownership of the thing. However inside the function block it is noise. Nothing inside the code is semantically different between the two forms, both do work on preexisting data. Certainly the second version could have a change where it does something with respect to the fact it is a smart pointers, changing what used to be a grabbed pointer to a weak pointer to be more explicit about lifetimes for instance. However that code change would be just as explicit as long as there aren't any methods on the smart pointer in the auto deref world.

This feels analogous to hiding in C++. In C++ by default member functions in a base class don't overload with member functions of the same name in a derived class. They get hidden.

quietbritishjim 3y ago

Not disagreeing with you but what's interesting is that C++ doesn't hide in this particular situation. Smart pointers implement operator-> and operator* but then ptr.foo() is still always the foo() method of the pointer type (and won't compile if it doesn't have it) - you need ptr->foo() or (*ptr).foo() to get the method of the pointed-to type. It's one of the few places that C++ is more explicit than Rust. I wonder if there's a reason Rust went a different way? I'm mainly a C++ programmer so I'm genuinely curious.

OskarS 3y ago
I've always liked that feature of C and C++. There's a lot of people that really hate it and in new languages they unify it to be just a dot. Zig does this as well, for instance. I always liked that the distinction was very explicit: use a.b() if you're calling b() on the object itself, use a->b() if you're de-referencing a first. There are lots of things wrong with C and C++ that Zig and Rust fixes, but I never thought of this one being problematic in any way. It's as easy to type, the difference is obvious, and it's easy to see from a glance what's going on.
- DixieDev 3y ago
  I'm mostly indifferent to it because it doesn't really harm readability, and it's not hard to know when to use it, but I can seem why it might be more strongly disliked. You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement. It's also annoying if you find that you can refactor `func(T*)` to `func(T&)` and now you have to replace all `->`s with `.`s.
  - codeflo 3y ago
    > You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement. To the extent that this is a problem, it's a problem with references as a language feature in general, not with the arrow syntax.
  - quietbritishjim 3y ago
    > You can't entirely rely on it to know a dereference is happening because references (e.g. `int&`) aren't subject to the `->` requirement. That's true but I think the bigger motivation is avoiding ambiguity than seeing when an indirection is happening. (You also can't see whether a method is virtual, i.e. indirecting via the vtable, from the call site.) In C++ references don't have any standalone methods or operators so there's no ambiguity from using methods via a reference just using a dot.
- codeflo 3y ago
  I'm among the people who would have liked to eliminate even this special case and have a convenient postfix derefence for this. So instead of a->b() you'd have a*.b(), and if you need to dereference again, write a**.b() and so on. But as you said, lots of people really seem to hate this kind of thing. Zig is almost there with its dereference syntax, but still kept the magic dereferencing dot.
  - mananaysiempre 3y ago
    Object Pascal strikes again: if a: ^record ... end is a pointer to a record, then a^ is the pointed-to record as a value and a^.b is the way you access a field of it. Incidentally, the authors of Go were asked why they didn’t use a postfix dereference when Sethi noted[1] back in 1981 that C syntax would have been simpler that way, was quoted in Ritchie’s 1993 retrospective[2] on that point, and even their own blog post on declaration syntax pointed out that possibility[3], but IIRC the answer amounted to “but then we wouldn’t have gotten those sweet, sweet C-bandwagon popularity points”. (I also cannot help calling out “Language X” here: One nice approach that nevertheless basically forces implicit dereferencing is that of Algon-68, where all values are constant values; the way to declare a mutable variable is to declare a pointer—a constant value—to a mutable cell; and the way to make the whole thing bearable is to have the compiler infer the minimum possible amount of dereferencing in an expression from the types of the values involved. Then of course it becomes impossible to infer the types, so the ML family goes with the inconvenient dereferencing, and you end up not really using a lot of mutability in ML.) [1] https://dx.doi.org/10.1002/spe.4380110606 https://dx.doi.org/10.1002/spe.4380110606 [2] https://dx.doi.org/10.1145/154766.155580 https://dx.doi.org/10.1145/154766.155580 [3] https://go.dev/blog/declaration-syntax https://go.dev/blog/declaration-syntax
- mr_00ff00 3y ago
  I have limited Zig experience, but actually zig is different from rust or go in this regard, correct? Rust and Go have the pointer have the unified syntax, but I thought in zig it does differentiate between the pointer itself and the value it points to. Rust and Go: ptr.method_on_ptr() ptr.method_from_underlying_val() Zig: ptr.method_on_ptr() ptr.*.method_from_underlying_val()
gpderetta 3y ago
People have been trying to get 'operator.' overloading in C++ for the last 20 years. Unfortunately this confusion between pointer operations and pointee operations has always been an obstacle :(.
mostlylurks 3y ago
One of the downsides of the C++ approach is that it makes it more cumbersome to make changes in your code. If you for instance make a trivial change where you change a variable from a stack-allocated object accessed directly via .foo() into a heap-allocated one accessed via ->foo(), you have to either manually change all .foo()s into ->foo()s or do some sort of weird work-around, such as making a separate variable that's a reference to the heap allocated object so that you can keep using those .foo()s. This is all relatively pointless busywork, which also pollutes the commit history with relatively meaningless changes.
- lionkor 3y ago
  those changes in access are semantically different, so i prefer being forced to change code when semantics change
  - Guvante 3y ago
    There is no sematic difference between passing in a reference and passing in a copy of a smart pointers though. Yes there is a difference at the call site between taking a reference to an owned thing and taking potential ownership of the thing. However inside the function block it is noise. Nothing inside the code is semantically different between the two forms, both do work on preexisting data. Certainly the second version could have a change where it does something with respect to the fact it is a smart pointers, changing what used to be a grabbed pointer to a weak pointer to be more explicit about lifetimes for instance. However that code change would be just as explicit as long as there aren't any methods on the smart pointer in the auto deref world.