Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
Haven’t read through this, but this sounds like what C++ is to C. I’m not sure adding more complexity and features to an already complex language is the right way forward. What is needed is a language that cuts down all the burden that has accumulated in C++ over 3 decades.
Something like Zig sounds like the better path forward to me. A completely new language from scratch with cross interoperability to C++. I’m surprised it’s not mentioned even once in the page.
I went for a blood test two days ago.
The girls came back sprinting with some papers, asking me how it was possible???
I asked calmly what was going on, right? That's when she said she never saw, in her entire life, such beautiful, elegant, fast and clean blood!
I was like: "darling, that's because Zig is flowing in my veins, I just can't stop using it"...
That being said, I totally agree with you.
This is cool in theory but this is yet another competing standard of static analysis.
We got clang-tidy, CPPAnalyser, etc… etc…
I am also curious how much of those "%70 of the vulnerabilities" would be detected by tools like valgrind, CPPcheck etc (either directly in the former case or indirectly in the latter). If a major part, then the main problem is people not incentivized to / not having enough time to use these tools.
Valgrind is pretty crazy to find bugs and memory leaks !
this is yet another competing standard of static analysis.
No, it isn't.
Those are linters. They might or might not discover problematic use of unsafe language features lurking in existing code.
This proposal is a new iteration of the language and standard library. It would provide safe language features for preventing such problems existing in the first place.
Right now, we have to compile the compiler for this ourselves. Pardon my skepticism; I’m not sure this is mature enough.
Edit: I’m talking about the project not the idea. Sean Baxter has shown up everywhere for awhile talking about this. I think his idea has a ton of maturity. I don’t know that the project itself has enough maturity to mainline yet.
That's fair. I think the last word in the URL does a good job of representing the implementation's claimed level of maturity:
draft
:)
You said
This proposal is a new iteration of the language and standard library. It would provide safe language features for preventing such problems existing in the first place.
Either it’s a draft or it’s a new iteration of the language. Can’t be both.
Either it’s a draft or it’s a new iteration of the language. Can’t be both.
It's a draft of a proposal for a new iteration. Is that so difficult to understand?
This is “It’s just a THEORY” but for programmers
It’s a concept of a plan
It's very hard for "Safe C++" to exist when integer overflow is UB. Rust also gets it wrong, though not quite in the same way. Ada gets it right.
By Ada getting it right, I assume you mean throwing an exception on any overflow? (Apparently this behavior was optional in older versions of GNAT.) Why is Ada's preferable to Rust's?
In Rust, integer overflow panics by default in debug mode but wraps silently in release mode; but, optionally, you can specify wrapping, checked (panicking), or unchecked behavior for a specific operation, so that optimization level doesn't affect the behavior. This makes sense to me; the unoptimized version is the same as Ada, and the optimized version is not UB, but you can control the behavior explicitly when necessary.
In Ada, the overflow behaviour is determined by the type signature. You can also sometimes use SPARK to statically guarantee the absence of overflow in a program. In Rust, as I understand it, you can control the overflow behaviour of a particular arithmetic operation by wrapping a function or macro call around it, but that is ugly and too easy to omit.
For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check. Wraparound for ordinary integers is simply incorrect. You might want it for modular arithmetic and that is fine, but in Ada you get that by specifying it in the type declaration. Also in Ada, you can specify the min and max bounds, or the modulus in the case of modular arithmetic. For example, you could have a "day of week as integer" ranging from 1 to 7, that traps on overflow.
GNAT imho made an error of judgment by disabling the overflow check by default, but at least you can turn it back on.
The RISC-V architecture designers made a harder to fix error by making everything wraparound, with no flags or traps to catch unintentional overflow, so you have to generate extra code for every arithmetic op.
It sounds like you're talking about dependent typing, then, at least for integers? That's certainly a feature Rust lacks that seems like it would be nice, though I understand it's quite complicated to implement and would probably make Rust compile times much slower.
For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check.
That's exactly what I described above. By default, trapping on overflow/underflow is enabled for debug builds and disabled for release builds. As I said, I think this is a sensible behavior. But in addition to per-operation explicit handling, you can explicitly turn global trapping behavior trapping on or off in your build profile, though.
In Ada? No dependent types, you just declare how to handle overflow, like declaring int16 vs int32 or similar. Dependent types means something entirely different and they are checked at compile time. SPARK uses something more like Hoare logic. Regular Ada uses runtime checks.
Whatever you want to call them, my point is that most languages, including Rust, don't have a way to define new integer types that are constrained by user-provided bounds.
Dependent types, as far as I'm aware, aren't defined in terms of "compile time" versus "run time"; they're just types that depend on a value. It seems to me that constraining an integer type to a specific range of values is a clear example of that, but I'm not a type theory expert.
Dependent types only make sense in the context of static typing, i.e. compile time. In a dependently typed language, if you have a term with type {1,2,3,4,5,6,7} and the program typechecks at compile time, you are guaranteed that there is no execution path through which that term takes on a value outside that set. You may need to supply a complicated proof to help the compiler.
In Ada you can define an integer type of range 1..7 and it is no big deal. There is no static guarantee like dependent types would give you. Instead, the runtime throws an exception if an out-of-range number gets sent there. It's simply a matter of the compiler generating extra code to do these checks.
There is a separate Ada-related tool called SPARK that can let you statically guarantee that the value stays in range. The verification method doesn't involve dependent types and you'd use the tool somewhat differently, but the end result is similar.
For what it's worth, Ada and Spark are listed separately in the Wiki article on dependent typing. Again, though, I'm not a language expert.
I'll look at the wiki article again but I can pretty much promise that Ada doesn't have dependent types. They are very much a bleeding edge language feature (Haskell will get them soon, so I will try using them then) and Ada is quite an old fashioned language, derived from Pascal. SPARK is basically an extra-safe subset of Ada with various features disabled, that is also designed to work with some verification tools to prove properties of programs. My understanding is that the proof methods don't involve dependent types, but maybe in some sense they do.
Dependent types require the type system to literally be Turing-complete, so you can have a type like "prime number" and prove number-theoretic properties of functions that operate on them. Apparently that is unintentionally possible to do with C++ template metaprogramming, so C++ is listed in the article, but actually trying to use C++ that way is totally insane and impractical.
I remember looking at the wiki article on dependent types a few years ago and finding it pretty bad. I've been wanting to read "The Little Typer" (thelittletyper.com) which is supposed to be a good intro. I've also played with Agda a little bit, but not used it for real.
It’s very hard for “Safe C++” to exist when integer overflow is UB.
You could simply state you did not read the article and decided to comment out of ignorance.
If you spent one minute skimming through the article, you would have stumbled upon the section on undefined behavior. Instead, you opted to post ignorant drivel.
Where does the document number come from? I can’t find anything about the SG or linked orgs that defines a sequence.
C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.
C++ programmers mocked languages for being dynamically typed then they introduced auto, they mocked JS for callback hell and introduced lambdas, they mocked Rust devs for being lowskill C++ devs who can't manage their own memory and now they are admitting they can't manage it themselves either.
It's going to be come like the x86 instruction set or windows that is backwards compatible with stuff from 30years ago just accumulating cruft, unable to let go.
auto isn't dynamic typing it's just type inference. It still has a fixed type you just don't have to write it. Like var in C#.
Lambdas are just a way of defining methods in place. It has nothing to do with callbacks.
But you're spot on for memory safety. Managing it yourself is risky and if it can be managed at zero cost it seems stupid not to.
auto isn’t dynamic typing it’s just type inference.
I'm aware, but one of the big arguments I've heard about dynamic typing is "I don't know which type it has when I read the code". Well, auto looks just like var in that regard.
Lambdas are just a way of defining methods in place. It has nothing to do with callbacks.
Callback definition from wikipedia:
In computer programming, a callback is a function that is stored as data (a reference) and designed to be called by another function – often back to the original abstraction layer.
This is exactly what lambdas are often used for in C++.
Well, auto looks just like var in that regard.
It really isn't. Neither in C# nor in Java. They are just syntactic sugar to avoid redundant type specifications. I mean things like Foo foo = new Foo();. Who gets confused with that?
Why do you think IDEs are able to tell which type a variable is?
Even C# takes a step further and allows developer to omit the constructor with their target-typed new expressions. No one is whining about dynamic types just because the language let's you instantiate an object with Foo foo = new();.
The problem with dynamic typing is you can't always figure out what the type is even with investigation as it can be lots of things based on what is passed or returned. It also allows incorrect values to be passed.
People will indeed make that readability argument but if the type is not obvious and important to understanding the code then it likely shouldn't be used there.
Keyword being "shouldn't". C++ doesn't care about that, it just hands you the loaded gun.
I wouldn't call bad readability a loaded gun really. Your dev tools will hopefully make it pretty easy to learn the type. It should be a minor inconvenience at best.
I wouldn’t call bad readability a loaded gun really.
Bad readability is a problem cause by the developer, not the language. Anyone can crank out unreadable symbol soup in any language, if that's what they want/can deliver.
Blaming the programming language for the programmer's incompetence is very telling, so telling there's even a saying: A bad workman always blames his tools.
C++ continues to be the dumping ground of paradigms and language features. This proposal just aims to add even more to an overloaded language.
I think you could not be more wrong even if you tried, and you clearly did not even read the proposal you're commenting on.
This proposal aims to basically create an entirely different programming language aimed at being easy to integrate in extsting codebases. The language just so happens to share some syntax with C++, but you definitely can't compile it with a C++ compiler because it introduces a series of backwards incompatible changes.
It's also absurd how you complain about introducing new features. Can you point out any language that is not absolutely dead that is not introducing new features with each release?
C++ programmers mocked languages for being dynamically typed then they introduced auto (...)
I'm sorry, you are clearly confused. The auto keyword is not "dynamically typed". It is called "auto" because it does automatic type deduction. It is syntactic sugar to avoid having to explicitly specify the type name in places the compiler knows it already. Do you understand what this means?
Your comment sounds like trolling, frankly.
Extend C++ for safety
I stopped reading after this. Why do you think C++ is unsafe in the first place? Someone decided ro extend it, and now you cannot even read an error message without finishing an university course on lambda calculus first.
