GNOME Might Need To Crack Down On Their JavaScript 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.

[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.

[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]

they only use C ABI if you explicitly request it. Usually, in safe rust code (i.e. outside unsafe{} blocks, the compiler is quite free when it comes to optimizations, however they mostly rely on llvm at the moment. Miri, an interpreter for their intermediate representation is in the works, which should prove interesting from optimizations point of view. It should greatly improve the handling of constants known at compile time.

I'm telling you that a compiler can easily see which variables are constants or not. What it can't, though, even with LTO, is whether an external function (a C-ABI function, you know, what I meant) modifies memory. But that's irrespective of language.

The ABI says that a function can clobber all of memory, except the stack (unless you pass a pointer to it). It doesn't matter if the function has const parameters/pointers; it can still do it (e.g. const_cast in C++), so a compiler *can not* assume that it doesn't. It doesn't know what the function does since it's external (unless it's builtin), so it cannot assume anything. It doesn't matter how "smart" it is, it just can't.

That's why I mentioned compiler limitations. Sometimes the programmer knows stuff that the compiler cannot know. If only the language allowed us to actually tell it that, just like restrict does... (maybe a gcc plugin or somesuch)

But no, they won't add it because "oh my god we need to shelter the programmers from their own mistakes, let's not add useful features to the language cause they can be mis-used by rookies and end up with broken code, but let's reiterate at the same time that compilers can do magic optimizations that they cannot know about!". (btw this last thing was a rant on C++ committee, not Rust, if you were misunderstanding it)

[oleid]

That's a function ABI thing, which Rust also has to respect, if it uses the same ABI (it should otherwise it wouldn't be able to use any libs). In most other cases the compiler can deduce what's const or not easily (in terms of optimizations).

they only use C ABI if you explicitly request it. Usually, in safe rust code (i.e. outside unsafe{} blocks, the compiler is quite free when it comes to optimizations, however they mostly rely on llvm at the moment. Miri, an interpreter for their intermediate representation is in the works, which should prove interesting from optimizations point of view. It should greatly improve the handling of constants known at compile time.

When you see "let mut" you see a variable declaration that's mutable which makes no sense.

it all doesn't make sense for you, since you don't understant, that „let” doesn't declare variables.

Nevertheless, I'm fed up with all this talk to no avail. Bye!

[Weasel]

That's the _static cast_ I was talking about. Casting by using a constructor call, but still casting. What I meant is writing something like

auto a = 5i64;

-- an imaginary C++ syntax for specifying the width of an integer.

No it's not a static-cast, it's a C-style cast with constructor syntax. And there's nothing wrong with it in this situation. It's also not any different than your example, other than having a bunch of parentheses.

But I know, "casts are evil" and so on, despite the harmless usage. Because let's learn by rote, that's what matters.

It compiles, maybe, however it will not necessarily work. Usually due to overflows (like: "uh, that worked on my 64bit platform, but why not on 32bit"?).

That's a programmer problem then, not the language issue. No different than trying to fit a 32-bit number in a int16_t. Usually it's the bad programmers who love throwing the "int" type around, anywhere.

I mean, if you don't know the type specs (int is minimum 16-bit, don't use it for larger values), then you don't know the language. How the hell is that the language's fault?

People are using rust on 8 bit µCs. What's the point?

Try 9-bit ones, then.

The whole point is, that people don't use const even if they could. I.e. for some temporary value. But if you had specified const, the compiler could have optimized better. Furthermore, it's easier to check if something has changed in case the scope of the object is large.

So you say that people don't use const, and somehow, it's the fault of the language? For real, man.

At least this weeds out the trash. People learn from mistakes too, so undoubtly some of the bad ones get polished.

The compiler doesn't optimize anything in respect to const, either, except when you use it within structs/classes because then it means something extra in C++ (language thing) and only under very specific circumstances (look up why std::launder was added to C++17 for more info). Stuff like function calls can clobber all memory (except the stack) and const isn't going to help at all there. That's a function ABI thing, which Rust also has to respect, if it uses the same ABI (it should otherwise it wouldn't be able to use any libs). In most other cases the compiler can deduce what's const or not easily (in terms of optimizations).

Variables are variables, constants are constants. There are no constant variables. Everything else is imprecise usage of English -- not that I'm using the terms correctly all the time.

I put it in quotes for a reason. When you see const declare something, you know it's a constant. Otherwise a variable. Having the defaults the other way around would make no sense. (this also answers your next question)

When you see "let mut" you see a variable declaration that's mutable which makes no sense. Maybe "let var" would make more sense. But "let" by itself is bad too, since it doesn't say it defines a CONSTANT in English. "const" does say it's a CONSTANT much better than "let".

I provided a code sample to illustrate what let is doing. You ignored it or didn't understand it. I don't see the point in wasting my time provide additional ones.

The C++ code snipplet a * b was to illustrate one of the many parsing ambiguties of C++, which the additional keyword let solves. As sniperfox wrote: "C and C++ don't need it because they trade away the flexibility of pattern declarations and that's totally fine". I'm trying to explain, why let is used in rust and why it would hardly work without it.

It wouldn't hardly work without it if it was designed less like a baby sitter. If people want to obfuscate their code, then let them. That's hardly a "negative".

Programmers need the babysitting, 40 years of pointer issues (especially after refactoring the code) disagree with you. Those modern features are not invented for no reason. People believing they make no mistakes are very dangerous. You seem to be one of them?

And people learn from mistakes, in every trade, skill, or profession, ever. Sheltering them from that... yeah, you'll end up with eventual garbage. That's already happening anyway.

That's the whole problem you seem not to understand. The usage of the key word let and constants by default makes it actually easier for programmers to parse the code in their heads. Reading the source is obviously not easier for you, however it's easier for the people actually using that language.

And how is that different than the C-flamers? Anything they say is for them, too.

It might surprise you, but "C fanboys" can also have their own opinions. So I can go ape-shit on their opinion that C is ugly or "not suited for application development" just as easily as you do on me. What the fuck.

[ssokolow]

Doesn't sound like such strong typing to me honestly.

It's perfectly strongly typed... it's just that numeric literals have types inferred from what you use them with unless you add a type suffix to them. (eg. let x = 1u64; )

It still has a strong, strict type and you'll get a compiler error if you try to use the same literal with variables of two different types without explicit conversion.

TL;DR: Integer and floating-point literals are strongly typed but implicitly typed by default.

[oleid]

int32_t(42)

int32_t is just a typedef to a type that is 32-bits.

That's the _static cast_ I was talking about. Casting by using a constructor call, but still casting. What I meant is writing something like

auto a = 5i64;

-- an imaginary C++ syntax for specifying the width of an integer.

They're minimum guarantees because they are portable languages. C/C++ work even on machines without 8-bit bytes and other such stuff.

It compiles, maybe, however it will not necessarily work. Usually due to overflows (like: "uh, that worked on my 64bit platform, but why not on 32bit"?).

A lot of "modern" languages don't even support 16-bit code (I mean, the segment memory model, which is a valid theoretical implementation even for modern CPUs, if you want to use it instead of paging, which may be overkill in some contexts, like DSPs).

People are using rust on 8 bit µCs. What's the point?

That has nothing to do with anything I said. When you write const you know it's a constant.

The whole point is, that people don't use const even if they could. I.e. for some temporary value. But if you had specified const, the compiler could have optimized better. Furthermore, it's easier to check if something has changed in case the scope of the object is large.

By default, variables are variables though, so should be mutable.

Variables are variables, constants are constants. There are no constant variables. Everything else is imprecise usage of English -- not that I'm using the terms correctly all the time.

Sure, go ahead and type const by default. No problem. This is not an issue because writing the code is not the problem, it's reading it. And assuming constant "variables" by default just doesn't click, since the term itself comes originally from something that is liable to change.

You're saying, defining constants is bad, since the naming in your head has an issue?

So reading "const" all over the place is not bad, it makes sense when you read it, and it should be there, not "the default". A "mutable" variable is also an oxymoron. Even in math, you have constants and variables.

Again, constants are constants, variables are variables, there a no constant variable and no mutable constant.

Begin with practical code and practical purposes maybe? Instead of theoretical Machiavelli attacks on the code. C++ doesn't prevent people from obfuscating their code,[...]

I provided a code sample to illustrate what let is doing. You ignored it or didn't understand it. I don't see the point in wasting my time provide additional ones.

The C++ code snipplet a * b was to illustrate one of the many parsing ambiguties of C++, which the additional keyword let solves. As sniperfox wrote: "C and C++ don't need it because they trade away the flexibility of pattern declarations and that's totally fine". I'm trying to explain, why let is used in rust and why it would hardly work without it.

programmers don't have to be babysit like "modern languages" seem to think.

Programmers need the babysitting, 40 years of pointer issues (especially after refactoring the code) disagree with you. Those modern features are not invented for no reason. People believing they make no mistakes are very dangerous. You seem to be one of them?

Well, IMO, I think making it easier for the compiler to parse is not such a good idea, because source code is for the programmer (humans), not compilers.

That's the whole problem you seem not to understand. The usage of the key word let and constants by default makes it actually easier for programmers to parse the code in their heads. Reading the source is obviously not easier for you, however it's easier for the people actually using that language.

[duby229]

Well, IMO, I think making it easier for the compiler to parse is not such a good idea, because source code is for the programmer (humans), not compilers. I honestly don't think anyone should care (not even compiler devs, because it's only done once vs the massive amount of projects using that language).

For example, and this is a criticism to C and C++ mind you, I hate the keywords that pollute the "global" namespace. C++ has two special "keywords" (they're not keywords), final and override. They're special because they're context sensitive, and in most cases, can be used freely as variable names and the like. They're ideally designed, and I wish all keywords were context sensitive like that.

It does make compilers harder to parse them, but who the fuck cares honestly? ALL keywords should have been context sensitive in my opinion. But whatever. So it's not like I think C/C++ are perfect by any means...

Now with C++ modules, they'll add some module-specific keywords, which is just disgusting to me, seeing as you'll only see those at the beginning of your source code -- in very specific circumstances. You'll, for example, never see them inside a function or class. What a fucking name pollution for no reason, to make "compilers easier", gah. I hate the C++ committee. You won't even be able to use the name "module" anymore. Disgusting.

They whine about the preprocessor a lot, but at least the preprocessor doesn't pollute the namespace as it needs the # sign on a new line and is completely separate.

Emergent behavior, that's all that needs to be said....

[Weasel]

Weasel just to clarify, let helps to disambiguate patterns. At least in Rust it tells the compiler "Whatever is after this phrase is garunteed to be a pattern". C and C++ don't need it because they trade away the flexibility of pattern declarations and that's totally fine. It's just two different design decisions. The only point being made is that let isn't there for no reason.

Well, IMO, I think making it easier for the compiler to parse is not such a good idea, because source code is for the programmer (humans), not compilers. I honestly don't think anyone should care (not even compiler devs, because it's only done once vs the massive amount of projects using that language).

For example, and this is a criticism to C and C++ mind you, I hate the keywords that pollute the "global" namespace. C++ has two special "keywords" (they're not keywords), final and override. They're special because they're context sensitive, and in most cases, can be used freely as variable names and the like. They're ideally designed, and I wish all keywords were context sensitive like that.

It does make compilers harder to parse them, but who the fuck cares honestly? ALL keywords should have been context sensitive in my opinion. But whatever. So it's not like I think C/C++ are perfect by any means...

Now with C++ modules, they'll add some module-specific keywords, which is just disgusting to me, seeing as you'll only see those at the beginning of your source code -- in very specific circumstances. You'll, for example, never see them inside a function or class. What a fucking name pollution for no reason, to make "compilers easier", gah. I hate the C++ committee. You won't even be able to use the name "module" anymore. Disgusting.

They whine about the preprocessor a lot, but at least the preprocessor doesn't pollute the namespace as it needs the # sign on a new line and is completely separate.