GNOME Might Need To Crack Down On Their JavaScript Extensions

[Sniperfox47]

Clearly you still don't understand what let is for. Maybe re-read my last post.

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.

[cybertraveler]

Yeah, but how is int32_t defined? That's what I was talking about and what I call difficult. For some nonsense reason, the standard types of C and C++ have only minimum guarantees and not a fixed size. That's a constant source of errors i.e. when serializing/deserializing stuff.

I think you're thinking of the ANSI C types like int, short & unsigned int. ANSI C had the problem you described. However C99 has solved the problem.

int32_t was introduced in C99 and it refers to a type that is a signed, exact-width, 32 bit integer.

int_least32_t behaves as you you thought int32_t behaved. Also introduced in C99, it refers to a signed, least width, 32 bit integer.

There's a nice section on wikipedia about these new types:

https://en.wikipedia.org/wiki/C_data_types#inttypes.h

[Weasel]

Nope, it defaults to Integer. The real bytes count is determined via the rest of the code. I.e. if you multiply your constant by 5i64, then the result the compiler would assume you meant a 64bit integer.

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

Yes, that's one of the problems I recently had with C++ in the context of tests and template variants. I didn't find a way to reliably create a 32 bit constant on any platform C++ supports, without using a static cast.

int32_t(42)

Yeah, but how is int32_t defined? That's what I was talking about and what I call difficult. For some nonsense reason, the standard types of C and C++ have only minimum guarantees and not a fixed size. That's a constant source of errors i.e. when serializing/deserializing stuff.

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

They're minimum guarantees because they are portable languages. C/C++ work even on machines without 8-bit bytes and other such stuff. 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).

The rest of the world doesn't agree with you. Please read the core guidelines again.

That has nothing to do with anything I said. When you write const you know it's a constant. By default, variables are variables though, so should be mutable. I never said you shouldn't use const when it matters. I said that it shouldn't be the default in the language. const makes it clear it's a constant "variable", so no ambiguity/oxymoron in your head.

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

I also disagree with a lot of the C++ committee, mind you. C++ is only good because of its roots in C, I don't think anyone will ever disagree with it. I mean, that's exactly what D is for, the "C++ without C" basically. So any committee member that thinks D is a good language should just GTFO C++ and go to "improve" D.

I always cringe when I see C++ code that's intentionally trying to avoid anything resembling C.

I don't even know where to begin...

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, like any proper language should, programmers don't have to be babysit like "modern languages" seem to think.

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

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

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

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

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

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

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)