GNOME Might Need To Crack Down On Their JavaScript Extensions

[GrayShade]

Weasel

So you think Rust's syntax is dumb because you don't like "let", but think "int derp(int arr[static const restrict volatile 5]);" is perfectly fine? Via. Anyway, others already tried to explain that "let" introduces patterns, not necessarily variables, and why immutable bindings are recommended (included in C++).

You asked a couple of pages ago what I didn't like about "const". I think it's mostly useless in C and C++ because it doesn't apply transitively through pointers and references. If you get a pointer to a const struct it means that you can't change it, without saying anything else about what happens:

• other code, on the same thread or others can change your struct
• the compiler has to reload the const data from memory if you've called other functions in the meanwhile
• you can unintentionally change data through your pointer because const is not transitive
• you don't know if the data you're accessing transitively is being modified by other code at the same time

So const imposes some restrictions while offering you no guarantees. That's considered to be a bad trade. In C++ you can at least introduce a smart pointer that propagates const-ness, and there are plans to do so. This has been regarded as an issue for a long time, but C++ had to work over the foundation of C. But because of that, even with a new smart pointer, you can never be guaranteed that "this object graph will never change".

Of course, if you're in the "good C and C++ programmers don't need that immutability crap" camp, there's not much more to argue about.

[Weasel]

So you think Rust's syntax is dumb because you don't like "let", but think "int derp(int arr[static const restrict volatile 5]);" is perfectly fine? Via. Anyway, others already tried to explain that "let" introduces patterns, not necessarily variables, and why immutable bindings are recommended (included in C++).

What exactly is bad about that example? It's perfectly readable and all of them serve a purpose. Except for volatile of course, but that's one of the very less used keywords in C and C++. (C++ doesn't even guarantee correct behavior when using it with std stuff, lol)

I thought you would bring a convoluted function pointer mess, since that's the only thing that C is not directly readable to someone who doesn't understand they need to start from the identifier and go in a spiral. I do admit function pointers are a bit arcane for newbies, but you don't see them that often... (never said C is perfect)

Re: const. What happens in Rust if you declare something const, and you don't modify it, but an external (library) function does? Since, you know, it's perfectly valid according to the ABI. Compiler can't "know" what the function does, since it's external. That's why in C they reload the variables, because they can't risk invalid code. The function could do a cast and write to a const parameter, it doesn't give a shit that the caller is Rust or not.

There are extensions like "pure" and "const" attributes on the functions but that's, obviously, compiler extensions.

[ssokolow]

Re: const. What happens in Rust if you declare something const, and you don't modify it, but an external (library) function does? Since, you know, it's perfectly valid according to the ABI. Compiler can't "know" what the function does, since it's external. That's why in C they reload the variables, because they can't risk invalid code. The function could do a cast and write to a const parameter, it doesn't give a shit that the caller is Rust or not.

If both the caller and callee are written in Rust and using the Rust ABI, then the compiler will verify that correct behaviour is preserved, no matter how many crates (libraries) your control flow passes through.

If they're communicating using the C ABI, then it's your responsibility to ensure that Rust's invariants are upheld and one of those invariants is that only one binding can be mut at any given time. Using casts to gain mut invokes undefined behaviour. (For the same reason that it's a bug to bypass a reader-writer lock in a threaded application for the sake of convenience. Think of Rust's type system as enforcing zero-overhead reader-writer locking on every variable binding using compile-time validation.)

That's one of the various reasons that FFI via the C ABI must be done within an unsafe block. Such a block tells the compiler to temporarily relax certain invariants on the promise that the programmer will have re-established any broken invariants by the end of the block. Proper Rust APIs wraip unsafe blocks in APIs which can only be used safely, thus simplifying debugging by narrowing down where the bug could originate.