3 ms·

Okay, so I came from C and this part really put me off. Why? Because I like saying what I mean, and meaning what I say. Nothing hidden, nothing implicit. And C,

Okay, so I came from C and this part really put me off. Why? Because I like saying what I mean, and meaning what I say. Nothing hidden, nothing implicit. And C, as opposed to C++, does not allow you to say something you don't mean. Here is one C++ example, without looking for the signature of f(), there's no way to tell the answer. So essentially two pieces of identical code with identical input values and no external side effects can still give you different output. Ah C++, the garbage that you are. int x = 5; f(x); // WHAT IS THE VALUE OF X HERE? int x = 5; f(x); // WHAT IS THE VALUE OF X HERE? So why is Rust any better in this regard? Because at the end of the day, Rust deals with actual concrete types and values, the only thing references are good for is being references: they sometimes save you some copying and let you refer to stuff and that's pretty much it. So the "ref1 == ref2" operation is a deep equality check and not a "does ref1 point to the same object as ref2" check. Because sometimes objects in different places in memory can be semantically equal. So it's okay for obj1 to mean obj1, &obj1 to mean obj1, &&obj1 to mean obj1, etc... If you need raw pointers like you need in C, because you know the objects you want to compare are singletons, then you can always cast using &obj as *const Obj or &mut obj as *mut Obj But that's an escape hatch. BTW, this auto-dereferencing you're experiencing is part of the Deref trait if you ever want to overload it. But that's, in my own opinion, an escape hatch as well. All in all, unless you're doing very specific things, try to write your code in high-level semantics (meaning using these deep-equality rather than pointer-equality semantics), and then benchmark and find out which parts are hurting your performance. Rust allows you to do that and still get between very-reasonable-and-very-good speed.

gpderetta 9y ago
int x = 5; f(x); // WHAT IS THE VALUE OF X HERE? if you really want to make sure that x is not changed by f, declare it const. Sure, f can cast the constness away, but then again it could also walk up the stack in C and trash your stack frame anyway. It is UB in either case. The typesystem in C++ can help protect against Murphy, but (unfortunately) not Machiavelli.
- fredmorcos 9y ago
  Agreed. But my example isn't about security or UB. It is about the language allowing you to write two IDENTICAL snippets of code that end up meaning two different things without any overloading involved. Like saying something and meaning something else.
  - gpderetta 9y ago
    int x[] = {5}; f(x); // WHAT IS THE VALUE OF X HERE? see, it works in C as well.
    - cesarb 9y ago
      In C, the value of x in that fragment is still the same: a pointer (ok, not exactly, but something which behaves like a pointer) to a memory location where an int can be stored. The f(x) call can't change that pointer.
      - int_19h 9y ago
        Try doing something like &x, and you'll see that it doesn't actually reliably behave like a pointer.
    - fredmorcos 9y ago
      So you get my point. 'x' is not going to be modified behind your back and it's pretty clear on the calling site. In C++ it isn't clear.
      - gpderetta 9y ago
        It is exactly the same between the two cases: the x object (either the array memory location or the integer memory location) can be changed by 'f' because mentioning the 'x' object name in a function call may implicitly converts to the address of the object, i.e. it passes by reference).
pjmlp 9y ago
> And C, as opposed to C++, does not allow you to say something you don't mean. More than 200 documented use cases of undefined behavior...
- fredmorcos 9y ago
  What does this have to do with syntactically expressing the same thing twice with two different semantic meanings?
  - pjmlp 9y ago
    That C compilers decide for themselves to say things that the programmer did not intended to do in first place, thanks UB.
simias 9y ago
>Okay, so I came from C and this part really put me off. Why? Because I like saying what I mean, and meaning what I say. Nothing hidden, nothing implicit. Are we talking about the same language here? The language where arrays implicitly decay to pointers, where integer types get implicitly promoted all over the place, where aliasing rules implicitly define which pointers can and cannot alias, where partial initialization of a struct or array implicitly sets the other members to 0? Where the language will let you call an undeclared function and make up a prototype on the fly for you? I also don't understand your C++ example, without side-effect why would both invocations of f() within the same scope produce a different result? I thought you wanted to criticise function overloading but you call it with an int both times so I don't see what's you're getting at. Or maybe you meant that the two calls are in a different scope and could resolve to a different function? But you can do that in C as well in two different translation units and making two static f() implementations.
- fredmorcos 9y ago
  > Are we talking about the same language here? The language where arrays implicitly decay to pointers, where integer types get implicitly promoted all over the place, where aliasing rules implicitly define which pointers can and cannot alias, where partial initialization of a struct or array implicitly sets the other members to 0? Where the language will let you call an undeclared function and make up a prototype on the fly for you? -Wall -Wextra and those issues are made clear to you. But granted, that's part of a good compiler and not part of the language. > I also don't understand your C++ example, without side-effect why would both invocations of f() within the same scope produce a different result? I thought you wanted to criticise function overloading but you call it with an int both times so I don't see what's you're getting at. I'm not criticizing function overloading. > Or maybe you meant that the two calls are in a different scope and could resolve to a different function? But you can do that in C as well in two different translation units and making two static f() implementations. Yes the two functions are different, but not necessarily in scope, they don't necessarily need to have the same names. Yet at the calling site they look exactly the same: one will modify your data without you being aware of it and the other will not, and there is no syntactic hint to differentiate them.
CyberDildonics 9y ago
Unless of course f is a macro, then x could have been modified.

gpderetta 9y ago

int x = 5; f(x); // WHAT IS THE VALUE OF X HERE? if you really want to make sure that x is not changed by f, declare it const. Sure, f can cast the constness away, but then again it could also walk up the stack in C and trash your stack frame anyway. It is UB in either case. The typesystem in C++ can help protect against Murphy, but (unfortunately) not Machiavelli.

fredmorcos 9y ago
Agreed. But my example isn't about security or UB. It is about the language allowing you to write two IDENTICAL snippets of code that end up meaning two different things without any overloading involved. Like saying something and meaning something else.
- gpderetta 9y ago
  int x[] = {5}; f(x); // WHAT IS THE VALUE OF X HERE? see, it works in C as well.
  - cesarb 9y ago
    In C, the value of x in that fragment is still the same: a pointer (ok, not exactly, but something which behaves like a pointer) to a memory location where an int can be stored. The f(x) call can't change that pointer.
    - int_19h 9y ago
      Try doing something like &x, and you'll see that it doesn't actually reliably behave like a pointer.
  - fredmorcos 9y ago
    So you get my point. 'x' is not going to be modified behind your back and it's pretty clear on the calling site. In C++ it isn't clear.
    - gpderetta 9y ago
      It is exactly the same between the two cases: the x object (either the array memory location or the integer memory location) can be changed by 'f' because mentioning the 'x' object name in a function call may implicitly converts to the address of the object, i.e. it passes by reference).

pjmlp 9y ago

> And C, as opposed to C++, does not allow you to say something you don't mean. More than 200 documented use cases of undefined behavior...

fredmorcos 9y ago
What does this have to do with syntactically expressing the same thing twice with two different semantic meanings?
- pjmlp 9y ago
  That C compilers decide for themselves to say things that the programmer did not intended to do in first place, thanks UB.

simias 9y ago

>Okay, so I came from C and this part really put me off. Why? Because I like saying what I mean, and meaning what I say. Nothing hidden, nothing implicit. Are we talking about the same language here? The language where arrays implicitly decay to pointers, where integer types get implicitly promoted all over the place, where aliasing rules implicitly define which pointers can and cannot alias, where partial initialization of a struct or array implicitly sets the other members to 0? Where the language will let you call an undeclared function and make up a prototype on the fly for you? I also don't understand your C++ example, without side-effect why would both invocations of f() within the same scope produce a different result? I thought you wanted to criticise function overloading but you call it with an int both times so I don't see what's you're getting at. Or maybe you meant that the two calls are in a different scope and could resolve to a different function? But you can do that in C as well in two different translation units and making two static f() implementations.

fredmorcos 9y ago
> Are we talking about the same language here? The language where arrays implicitly decay to pointers, where integer types get implicitly promoted all over the place, where aliasing rules implicitly define which pointers can and cannot alias, where partial initialization of a struct or array implicitly sets the other members to 0? Where the language will let you call an undeclared function and make up a prototype on the fly for you? -Wall -Wextra and those issues are made clear to you. But granted, that's part of a good compiler and not part of the language. > I also don't understand your C++ example, without side-effect why would both invocations of f() within the same scope produce a different result? I thought you wanted to criticise function overloading but you call it with an int both times so I don't see what's you're getting at. I'm not criticizing function overloading. > Or maybe you meant that the two calls are in a different scope and could resolve to a different function? But you can do that in C as well in two different translation units and making two static f() implementations. Yes the two functions are different, but not necessarily in scope, they don't necessarily need to have the same names. Yet at the calling site they look exactly the same: one will modify your data without you being aware of it and the other will not, and there is no syntactic hint to differentiate them.

CyberDildonics 9y ago

Unless of course f is a macro, then x could have been modified.